samagotchi 0.132.0 → 0.134.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: ebe264e1dbd5adc620889aa40d66fd458519c64f038a3a3e5de06ee6a6da46e7
-  data.tar.gz: 3c72148287422c9821c25bc3979c71890fb4abad81af3829650aef3c13549a3f
+  metadata.gz: 1400c2aa3cceb5a84b6aa0d5610021b5e5893415afa37f98e8c99efe291de436
+  data.tar.gz: eda23134194381fd10460ba0b026ae10aa5a8aaf674fbc9dc4504359b1acb86d
 SHA512:
-  metadata.gz: f8ffaf8ca17c125a38af6a30432d8b14a66ea97df8201686acedca8dde11869845b0e2a6abe0f9ece18db4e5848f9340b2ef73910371977fafe9889d430eebad
-  data.tar.gz: e556232bbad1093cff1779510162a179b1284cc90bd8cc54d8082e2a4dab5e96f98bb6ebae5ef99ab82610a1bd33880c830cfae8b1076d1e6ca841c406ae45b3
+  metadata.gz: 7029cb713c02b4c3099ade377bc57618ec6467c2a1f04a4b21c7ebd3fbb6e34705e1ad54fe547672becdc6553824b785c96222e310690fd707a12c0fb057e852
+  data.tar.gz: e7400f091254ba9ffdf04f14160e8d6816cbe264016f8be8558c9da091edcc33bf34ed93652c83b6647be728a349b31631db49fc26e483280deda75a7658e5e3

data/CHANGELOG.md

@@ -7,6 +7,112 @@ and commands may change between minor versions. How releases are made:
 [docs/releasing.md](docs/releasing.md).
 ## [Unreleased]
 
+## [0.134.0] - 2026-10-30
+
+### Added
+
+- Web: a long answer (over ~25 lines or ~2,000 characters) gets a fold row above it: one click folds it to its first
+  line and its length, another opens it. Your folds are kept per browser across reloads; a jump into a folded answer
+  (a claim link, the working set, "View check") opens it.
+
+### Fixed
+
+- Web: the start page's ⚙ and 🧰 buttons say whether their panel is open (`aria-expanded`) to screen readers.
+- Web: an open sheet or popover is placed again when the window resizes (a rotation, a phone's keyboard): its header
+  no longer ends up above the screen, and a sheet turns back into a popover on a wide window.
+- Web: on a phone the ⚙ panel's sheet may take 85 % of the screen, so with "Apply and budget" open its closing note is
+  no longer cut off at the bottom edge.
+- Web: the ⚙ and 🧰 panels keep the keyboard focus while open (Tab wraps inside, `aria-modal`), their override chips
+  say whether the panel is open (`aria-expanded`), and Esc or × gives focus back to the chip that opened it.
+- Web: "default" on the ⚙ panel's Context row now clears a set apply rule and budget too: the chip read "ctx apply
+  payoff · budget 64000" while the row showed default, and the new session got them.
+- Web: on a touch screen a tapped row or link in the ⚙ and 🧰 panels (and the ⚙ and 🧰 buttons) no longer keeps its
+  hover tint.
+- Web: a sheet's and a popover's × is a 36 px tap target on a touch screen (it was 22x16 px).
+- Web: the Stop sheet's "+N more" no longer sits 74 px to the right (it shared a class with the ⚙ panel's row).
+- Pair turns: a read-only mention of mise's config (`find . -name mise.toml && make`) no longer asks the owner; a
+  delete, move or write of it still does, and `.tool-versions` (mise reads it too) is covered the same way.
+- `chi home doctor` checks the desktop helper only when the helper's chi reads this chi's config dir: a run with
+  `XDG_CONFIG_HOME` elsewhere no longer reports the installed helper against a home it never boots.
+- The new-version hint ("… the desktop helper can be updated: chi update") follows the same rule: a run with
+  `XDG_CONFIG_HOME` elsewhere no longer hints about the installed helper.
+- `chi home set` under `bundle exec` refuses to record its own Ruby, whose gem path is the bundle's, instead of making
+  it the home every launch boots (`--ruby` another Ruby still works).
+- `chi update` under `bundle exec`, run on another Ruby than the chi home's, hands over to the home's chi outside the
+  bundle instead of loading the bundle into it (which failed noisily).
+- `chi self`'s home row says when this chi runs on the home's Ruby and gems but isn't the home's newest chi (`this chi
+  is X`), as the terminal line and `chi home doctor` do.
+- `chi home doctor` reports a worker that couldn't boot the chi home's chi (the debug log's newest `boot_failed` line
+  since the home was set, unless a worker started after it), with what to run.
+- Toolkit suggestions (`toolkit.suggest.mode: on`): a suggestion that times out or gets no answer from System 1 now
+  says so in a notice (the session runs its default kit) and a timeout logs a warning, instead of falling back silently.
+- Pair turns: a participant can no longer write git's config at all, so no setting makes git run a command later in
+  your name (a hook, a filter or driver, a helper, an include): `git config` only reads, parsed strictly (an unknown or
+  abbreviated option counts as a write), and `git -c`, `--config-env`, a clone's `-c`/`--config`, `--template` and
+  `GIT_TEMPLATE_DIR` are denied, as are a submodule's hooks (`.git/modules/*/hooks`) and the hook installers
+  (`pre-commit install`, `husky`, `lefthook install`). A command git runs from its text (`rebase --exec`,
+  `submodule foreach`) is checked like any command. Reading git's config (`git config --get`, `-l`) is no longer
+  refused.
+- Pair turns: a command that writes outside the project with no word naming where now asks you like any other
+  outside write: global installs (`npm -g`, `pip install`, `gem install`, `brew`, `cargo`/`go install`, `pipx`,
+  `uv tool`), user config (`npm config set` writes `~/.npmrc`, `gh config set`), `defaults write`, `launchctl`; and
+  so does a shell or interpreter reading its script from stdin (`… | sh`, `| bash -x`, `curl … | bash`,
+  `sh < run.sh`). Global installs are recognised in any spelling (`npm i --location global`, `python3.12 -m pip`,
+  `npm_config_global=true`, `npm link`), with more tools (`deno`, `dotnet tool`, `corepack`, `bundle config set`).
+- System 1 no longer auto-allows a command that names the memories folder and then climbs out of it by a script's
+  own calls (`python3 -c '…os.chdir(os.pardir)…'`, `ruby -e '…File.dirname(Dir.pwd)…'`) or runs a script it can't
+  see (a file, stdin, `| sh -x`, `python3.12 x.py`, `make`, `awk -f`): it could write `config.yml`. You decide
+  those; plain memory edits stay eligible.
+- Guardrails: a `task_create` whose `env:` points git at another config (`GIT_CONFIG_GLOBAL`, `GIT_CONFIG_SYSTEM`,
+  `GIT_CONFIG_KEY_n`/`VALUE_n`) is no longer read-only, and a pair turn's command that sets one is denied like
+  `git -c`.
+- Pair turns: more spellings that hid a git config write or a command are caught: a git global option that takes a
+  value (`--attr-source`, `--shallow-file`, one git adds later), `git-config` and the other dashed builtins, a script
+  after a shell's options (`sh -c -- S`, `bash -c -x S`) or in an option cluster (`ruby -we`, `perl -le`, `node -pe`,
+  `python3 -Ic`), and a command handed through an environment variable (`GIT_EDITOR`, `GIT_SSH_COMMAND`,
+  `GIT_EXTERNAL_DIFF`, `GIT_PAGER`, `EDITOR`, …). `git maintenance register/start`, `git lfs install` and
+  `scalar register` now ask you.
+
+## [0.133.0] - 2026-10-30
+
+### Added
+
+- Sessions follow their project: a session's worker reads its folder's `mise env` once at start, and `execute`,
+  tasks, `!cmd`, MCP servers and context sources run in it, getting the project's Ruby (and node, …) whoever started
+  the worker (`session.project_env: mise`, the default; `off` skips mise). chi's own process keeps its
+  env (its keys, proxies and config never come from a project). The starter's GEM_HOME/GEM_PATH are dropped when the
+  Ruby changes. `chi` inside those tools stays the chi home's (a `chi` script in `$XDG_STATE_HOME/samagotchi/bin`). A
+  mise.toml edit needs `chi sessions restart`; a `mise env` that fails (an untrusted mise.toml) changes nothing and
+  logs one `project_env` warning. A session started from a tool for another folder never gets this one's env.
+  `chi self` shows `home` and `project env`. See docs/sessions.md (Project env).
+- Pair turns: their `execute` runs without the project env; a command that runs `mise` or `direnv`, and a write to
+  mise's config (the owner's next worker start runs it), ask the owner; `.envrc` and mise's local files are secrets,
+  as `.env` is.
+- Bundles: mcp 0.7.3 starts its servers in the session's project env.
+- `chi home doctor` checks what should follow the chi home, one row each with `ok`/`warn`/`fail` and the command to
+  run: the chi you ran, the desktop helper's launch file (`chi desktop upgrade`), sessions saved by a newer chi than
+  the home's, the tools' `chi` script, a Gemfile.lock in this project that bundles samagotchi, mise, and the last
+  worker's `project_env` warning in this folder (e.g. `mise trust`). See docs/configuration.md (Checking it).
+- A chi run at a terminal on another Ruby than the chi home's says so in one dim line, at most once a day
+  (`chi X on <ruby>; the chi home is <ruby> (chi Y) (chi home doctor)`).
+- Web start page: a 🧰 beside ⚙ picks the new session's toolkit. **Auto** (the default, nothing sent) leaves the
+  first message to `toolkit.suggest.mode: on`'s suggestion when one can come, else `toolkit.default`; a picked kit is
+  sent (no suggestion then) and shows as a `tools: lean` chip (a dot on a phone). The list holds the built-in and
+  config kits a new session can start on; `GET /api/models` lists them as `toolkits`. A kit Start refuses is said in
+  the list. See docs/configuration.md (Toolkits).
+
+### Changed
+
+- Web start page: thinking, LLM context and review files move into one ⚙ panel beside the model picker (a bottom
+  sheet on a phone): each a row of segments that applies at once, the first one the picked model's own
+  (`default (high)`), the context's apply rule and budget under **Apply and budget ▸**, and **Review files…** as a
+  view of its own. Only what is set shows on the row, as accent chips (`think high`, `ctx stale`,
+  `review: README.md`) that open the panel; on a phone ⚙ carries a dot instead. Still for the next new session
+  only. See docs/configuration.md (A new web chat).
+
+Update with `chi update` (mcp 0.7.3), then restart `chi web` and the session workers (`chi sessions restart`). If
+you use the desktop helper, run `chi desktop upgrade` once; `chi home doctor` says what else to do.
+
 ## [0.132.0] - 2026-10-29
 
 ### Added
@@ -5037,7 +5143,9 @@ and long-lived sessions.
 - A macOS desktop helper (`chi desktop install`): a "Send to chi" Service and a
   hotkey panel that send selected text or the clipboard to your sessions.
 
-[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.132.0...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.134.0...HEAD
+[0.134.0]: https://github.com/dm1try/samagotchi/compare/v0.133.0...v0.134.0
+[0.133.0]: https://github.com/dm1try/samagotchi/compare/v0.132.0...v0.133.0
 [0.132.0]: https://github.com/dm1try/samagotchi/compare/v0.131.0...v0.132.0
 [0.131.0]: https://github.com/dm1try/samagotchi/compare/v0.130.1...v0.131.0
 [0.130.1]: https://github.com/dm1try/samagotchi/compare/v0.130.0...v0.130.1

data/bin/chi

@@ -8,6 +8,14 @@ $LOAD_PATH.unshift(File.expand_path("../lib", __dir__))
 require "samagotchi/utf8_default"
 Samagotchi::Utf8Default.apply!
 
+# A chi a session's tool runs: back to that worker's own env before anything
+# reads config (its API keys and proxies, not the project's mise env), and
+# the workers it starts never take the project's (docs/sessions.md, Project env).
+if ENV.key?("SAMAGOTCHI_PROJECT_ENV_ORIG")
+  require "samagotchi/project_env"
+  Samagotchi::ProjectEnv.take_orig!
+end
+
 require "samagotchi/config"
 
 begin
@@ -27,6 +35,14 @@ if ENV.key?("SAMAGOTCHI_WEB_RESTARTED") || ENV.key?("SAMAGOTCHI_WEB_ADOPT_PIDS")
   web_restarted = Samagotchi::Web::Server.take_restart_env!
 end
 
+# A person's chi at a terminal on another Ruby than the chi home's: one dim
+# line a day saying so (HomeNotice: never in a worker's tools, a script or
+# machine output).
+unless web_restarted
+  require "samagotchi/home_notice"
+  Samagotchi::HomeNotice.show
+end
+
 # `chi self`: print version, source dir, config/memory/session paths, model and
 # bundles (read-only, offline) — lets the agent find its own code and state.
 if ARGV[0] == "self"

data/docs/architecture.md

@@ -158,11 +158,38 @@ home's Ruby is gone, when no `samagotchi-*.gemspec` is under its gem path, and f
 | `Desktop::MacOS#launch_config` | argv `CHI_BOOT + ["--"]`; `launch_ok?` / `launch_problem` check only absolute argv entries | `[ruby, wrapper or bin/chi]` |
 | `InstalledVersions`, `Web::UpdateCheck` | the home's specification dirs and gem dir | the running process's |
 
-Unchanged: `ContextProviders`' `{ruby}` (`RbConfig.ruby`: the home's ruby inside a home worker), `chi bundle
+Unchanged: `ContextProviders`' `{ruby}` (`RbConfig.ruby`: the home's ruby inside a home worker; it runs under the
+project env below, so a `mise env` that sets GEM_HOME reaches it), `chi bundle
 try/test/check` (`-I LIB_DIR`), hooks (in-process). The worker's boot string, `run_session_loop(id, state_dir:)` and
 `SAMAGOTCHI_BOOT_FALLBACK` stay the cross-version contract (`spec/worker_contract_spec.rb`): the home only adds the
 prelude in front. An older chi that wakes a session doesn't read home.json and starts its worker as before.
 
+**The tools a worker runs** follow the project, not the boot, and only they do: a spawned worker
+(`WORKER_PROCESS_ENV`; never an in-process loop) calls `ProjectEnv.compute` in `run_session_loop`, after the owner
+lock and before `Worker.new`, and installs the result (`ProjectEnv.install!`; a frozen `ProjectEnv::Overlay`,
+`{key => value or nil}`). Its ENV is never written: chi's own process (LLM calls, `HostKeys`, Net::HTTP proxies,
+Config, Paths, hooks, plugins) keeps the spawner's env. The overlay is the session folder's `mise env -C DIR --json`
+(mise's `__MISE_*`/`MISE_SHELL` unset; the spawner's GEM_HOME/GEM_PATH unset when the first `ruby` on PATH changes,
+unless mise sets them; never `HOME`, `XDG_*`, `SAMAGOTCHI_*`, `CHI_REMOTE`, `RACK_ENV`, `CI`), `ChiShim`'s dir
+(`$XDG_STATE_HOME/samagotchi/bin`, only a `chi` that execs `Record#boot_argv(run: CHI_BOOT)`) first on PATH when there
+is a home, `SAMAGOTCHI_PROJECT_ENV` (`mise:<ruby>` or `none:<reason>`, for `chi self`) and
+`SAMAGOTCHI_PROJECT_ENV_ORIG` (the worker's own value of each key it changes). It is merged into: `execute` and
+`task_create` for the owner's turns (`Builtins.project_env`, less `TaskRuntime::SANITIZED_ENV_KEYS`; never a
+participant's turn), `!cmd` (`SessionCommands#shell`), context sources (`ContextFetch`) and MCP servers (the mcp
+bundle's `server_env`). A worker started from the worker inherits its clean ENV. A `chi` a tool runs (through the shim or not, a fresh
+process with the tools' env) takes the worker's values back from the record in `bin/chi`, before anything reads
+config (`ProjectEnv.take_orig!`): its own API keys and proxies, and the env of any worker it starts, are the
+worker's (`ChildEnv` still drops the record and marker for a child). `restore_env` never returns a reserved key and
+returns `DYLD_*`/`LD_*`/`RUBYOPT`/`RUBYLIB`/`RUBYGEMS_*`/`BUNDLE*` only as unsets. Hooks run in-process, with the
+worker's env. Specs never reach a real mise: `SAMAGOTCHI_MISE_CLI` (only that path when set) points at a missing
+file. User side: [sessions.md](sessions.md#project-env).
+
+**Checking it.** `chi home doctor` (`HomeDoctor`) reads home.json and what should follow it, each condition's text
+from its owner: `ChiHome.problem`, `HomeNotice.mismatch` (also the once-a-day notice `bin/chi` prints at a TTY on
+another Ruby), `Desktop::MacOS#launch_problem` / `#home_problem`, `ChiShim.problem`, `ProjectEnv::NO_MISE` and
+`ProjectEnv.last_warning` (the newest `project_env` / `project_env_applied` record for the folder, from the debug
+log's last 4 MB). Rows: [configuration.md](configuration.md#checking-it-chi-home-doctor).
+
 ## Session retention & ordering
 
 - **Files:** `~/.local/state/samagotchi/sessions/<uuid>.json` + `<uuid>/input|output|owner.lock|bridge.json` (XDG-aware), and the `<uuid>/stopped` and `<uuid>/archived` marker files.

data/docs/cli.md

@@ -35,7 +35,7 @@
 - `chi models [--format text|json] [--timeout S] [TEXT]` — list the models every configured host offers, as the names `--model` takes (see [Listing the models](#listing-the-models))
 - `chi self` — print version, source dir (checkout or installed gem), config/memory/session paths, model/host and bundles. Run by a session's `execute`, the `model` row (and host, loop, profile, thinking, served model) is **that session's** model, labelled `(this session <id8>; default …)`; elsewhere it is the default, `(default)`. `model key` is the memory overlay key (`<name>.<key>.md`), and `model notes` the model notes a prompt of that model loads (`model_notes_deepseek (system, 612 chars)`, `none`; inside a session its `--mute` list is left out). `chi self --model` prints only the model a new session starts on, an alias resolved to its target (the desktop helper's hint)
 - `chi update [--dry-run] [--to VERSION] [--json] [--no-gem] [--no-bundles] [--no-desktop]` — update an installed chi: the gem, the system bundle, the shipped bundles you installed and the desktop helper, in one table (see [Updating](#updating))
-- `chi home`, `chi home set [--ruby PATH]`, `chi home doctor` — the chi home: the one Ruby (and its gem path) every chi launch boots, whoever launches it. `chi home` shows it (its Ruby, the newest chi in it, gem home and path, `mise`, when and by which chi it was set, and the chi you ran when that is another one; exit 1 with the problem when it can't boot chi), `set` records this chi's Ruby and gem path (or `--ruby PATH`'s own; it must have samagotchi), `doctor` checks it (for now: its Ruby is there and has samagotchi; exit 1 says what to do). This machine only (see [The chi home](configuration.md#the-chi-home))
+- `chi home`, `chi home set [--ruby PATH]`, `chi home doctor` — the chi home: the one Ruby (and its gem path) every chi launch boots, whoever launches it. `chi home` shows it (its Ruby, the newest chi in it, gem home and path, `mise`, when and by which chi it was set, and the chi you ran when that is another one; exit 1 with the problem when it can't boot chi), `set` records this chi's Ruby and gem path (or `--ruby PATH`'s own; it must have samagotchi), `doctor` checks it and what should follow it, one row each with `ok`, `warn` or `fail` and what to run (exit 1 on a `fail`; see [Checking it](configuration.md#checking-it-chi-home-doctor)). At a terminal, a chi on another Ruby than the home's says so in one dim line a day. This machine only (see [The chi home](configuration.md#the-chi-home))
 - `chi bundle install|upgrade|uninstall|status|diff|list|build|trash|new|test|check` — manage memory bundles (see [Bundle hooks](hooks.md#bundle-hooks-unified-workflow-bundle)); `list` shows the installed ones and the ones shipped with chi, which `install <name>` installs; `core` and `dev` are profiles that install a set of them (see [Bundle profiles](memory.md#bundle-profiles-core-and-dev),  [Guardrails](guardrails.md), [Plugins](plugins.md#the-btw-bundle), [the mcp bundle](plugins.md#the-mcp-bundle) [the loop-guard bundle](plugins.md#the-loop-guard-bundle), [the check-in bundle](plugins.md#the-check-in-bundle) and [the skills bundle](plugins.md#the-skills-bundle)). `trash` lists and empties the bundle trash (moved files from uninstalls/upgrades). A usage error (an unknown subcommand or flag, a missing argument, a bad `build --scope`) exits 2, as for the other subcommands. Plain `chi` and `chi web` exit 1 on an unknown flag, a flag missing its value or a stray argument. `new`, `test` and `check` are for writing one: see [Writing a bundle](#writing-a-bundle-new-test-check)
 
 - `chi guardrails replay [--dry-run] [--threshold T] [--model M]` — seed System 1's record from the approvals this machine's sessions already answered: each ask is judged by the configured model and written to `guardrails/judgments.jsonl` with the answer the user gave, then a per-rule table prints (asks, allowed, denied, would-be auto-allows, false allows, asks with no judgment). A parent agent's answer is not the user's: only its deny is replayed, and only where the parent could have allowed. `--dry-run` judges without writing, `--threshold` overrides `guardrails.system_one.threshold` for the table, `--model` the configured model for this run. Exit 2 when `guardrails.system_one.mode` is off or no `host` is set; a usage error exits 2 (see [System 1](guardrails.md#system-1-experimental))
@@ -1026,6 +1026,17 @@ touch screen), and so does each code block of a rendered answer. An answer
 copies its Markdown source, not the rendered text; a code block copies just
 its code; a prompt copies the text as you typed it.
 
+A long answer (over 25 lines or 2,000 characters of its text) can be folded
+by hand: a slim "▾ N lines" row sits just above it once its turn has ended.
+Click it and the answer folds to one row, "▸ its first line · N lines" (the
+first line of what a hook presented in its place, else its first heading,
+else its first line); click again to unfold. A delegate report's reply
+folds the same way. Folding is this browser's choice, kept per session in
+localStorage (`chi_answer_fold:<session id>`, the last 200 folded answers;
+the keys of sessions gone from the list are dropped when the list loads);
+other viewers and the participant page are not affected. A jump into a
+folded answer (a claim link, say) unfolds it for that page load.
+
 ### Web views
 
 `web.view` picks how the page draws a turn: `stage` (the default: the

data/docs/configuration.md

@@ -70,6 +70,7 @@ model_aliases:
 session:
   shared: true
   # idle_exit_minutes: 30   # an unused worker exits after this (0 = never)
+  # project_env: mise      # a worker's tools get its folder's `mise env` (off: the starter's env)
   # keep_empty: false       # true keeps sessions nothing happened in (default: deleted when left)
   # max_children: 4         # running sessions one session may have delegated at a time (the delegate tool)
   # delegate_reports: wake  # a child's reply reaches its parent by itself: wake (an idle parent runs a turn), queue, off
@@ -171,7 +172,7 @@ or `chi web` restart.
 | `hooks`, `bundles` | Worker start | Hooks, plugins and their bundle settings load with the engine. |
 | `recap.*` | Worker start | The engine builds its recap job at start, and again when it binds a session with its own `recap.enabled` or `recap.sentences` (`--set`, see "Per-session settings") and when `/recap on\|off\|default` changes the session's own value. |
 | `session.shared` | Next `chi` invocation | It selects attached-worker or in-process mode for that invocation. |
-| `session.idle_exit_minutes`, `session.keep_empty`, `session.max_children`, `session.delegate_reports`, `session.task_wakes`, `session.max_wakes` | Worker start or next matching lifecycle decision | Existing workers keep their idle-exit timer; the other values are read for the next corresponding decision. |
+| `session.idle_exit_minutes`, `session.project_env`, `session.keep_empty`, `session.max_children`, `session.delegate_reports`, `session.task_wakes`, `session.max_wakes` | Worker start or next matching lifecycle decision | Existing workers keep their idle-exit timer and project env; the other values are read for the next corresponding decision. |
 | `session.retention_*`, `session.max_count`, `session.keep_status`, `session.sweep_interval_hours` | Next retention sweep | `chi web` sweeps on its configured schedule and on `GET /api/sessions`; `chi sessions prune` uses the values for that invocation. The sweep interval is checked on the next hub tick. |
 | `web.*` except `web.participants.*` | `chi web` start | Restart `chi web` to change its bind address, port or page settings. |
 | `log.*` | Process start | Each process holds its configured log sink and level after first use; restart that process. |
@@ -655,7 +656,7 @@ models:
     came from);
   - `chi --thinking LEVEL` on a run that starts or resumes a session (the REPL, `-p`, `--resume`, an attached one);
   - `chi send --new --thinking LEVEL`;
-  - the web's `think` chip, in the session bar and on the start page (`POST /api/sessions` takes `"thinking": "low"`;
+  - the web's `think` chip in the session bar, and the start page's ⚙ panel (`POST /api/sessions` takes `"thinking": "low"`;
     anything that isn't a level answers `400 invalid_thinking`).
 - `chi web --thinking LEVEL` is the default for the sessions its workers run, below a session's own. A session started
   with only the env (`SAMAGOTCHI_THINKING_LEVEL=low chi send --new …`) loses the level when a worker without that env
@@ -1374,7 +1375,8 @@ launches it. It is recorded in `~/.config/samagotchi/home.json` (`$XDG_CONFIG_HO
 - **Setting it.** `chi home set` records the Ruby your `chi` runs on and its gem path (a chruby shell's
   `GEM_HOME`/`GEM_PATH` are part of it: that is where its chi lives); `chi home set --ruby PATH` records another
   Ruby with its own gem dirs. Either needs samagotchi installed there (`gem install samagotchi` with that Ruby
-  first). Without a home.json, the first `chi bootstrap` or `chi update` records one, once (from an installed chi,
+  first). Under `bundle exec`, `chi home set` refuses to record its own Ruby (the bundle's gem path is no home);
+  `--ruby` another Ruby still works. Without a home.json, the first `chi bootstrap` or `chi update` records one, once (from an installed chi,
   never under `bundle exec`): of the desktop helper's Ruby (when its newest chi is at least the one running) and the
   Ruby chi runs on, the one with the newer chi. Nothing else ever overwrites it.
   `chi home` shows it; `chi home doctor` checks it (see [CLI](cli.md#commands)).
@@ -1383,8 +1385,9 @@ launches it. It is recorded in `~/.config/samagotchi/home.json` (`$XDG_CONFIG_HO
   runs the home's `chi update`, and installs into the home's gems with the home's `gem`), `chi bootstrap`'s
   commonmarker install, chi web's "installed; restart" notice and the macOS helper after its next `chi desktop
   install` or `upgrade`. The boot sets the home's gem path inside Ruby (`Gem.paths`), never in an environment
-  variable: the commands a session runs (`execute`, tasks, `!cmd`, MCP servers) keep the GEM_HOME/GEM_PATH of whoever
-  started the worker, or none. How: [How chi launches itself](architecture.md#how-chi-launches-itself).
+  variable: the commands a session runs (`execute`, tasks, `!cmd`, MCP servers) follow the session's project (its
+  `mise env`, [Project env](sessions.md#project-env)), and their `chi` is the home's. How:
+  [How chi launches itself](architecture.md#how-chi-launches-itself).
 - **No home, or one that can't boot chi** (its Ruby gone after a Ruby upgrade, samagotchi uninstalled there, a
   home.json that isn't JSON): each launch uses the Ruby that starts it, as without a home, and the log says why once
   per process (`home_unusable`, `home_invalid`). After a Ruby upgrade: `gem install samagotchi` with the new Ruby,
@@ -1394,9 +1397,34 @@ launches it. It is recorded in `~/.config/samagotchi/home.json` (`$XDG_CONFIG_HO
   `home_older_than_spawner`), but chi web's restart runs the newest chi it knows outside the home instead
   (`restart_home_older`): its flags may be ones the older chi doesn't know.
 - **A home that still fails at boot** (a broken install): the worker writes one `boot_failed` line to the debug log
-  (`log.file`) and exits, rather than leave the spawner waiting.
+  (`log.file`) and exits, rather than leave the spawner waiting; `chi home doctor` reports the newest one.
 - Each machine has its own home (a remote's is that machine's).
 
+### Checking it: chi home doctor
+
+`chi home doctor` prints one row per check, `ok`, `warn` or `fail`, each with what to run; it exits 1 when a row
+fails (a launch can't boot what it should), 0 otherwise. Run it in a project folder to check that project too.
+
+| Row | When | What to run |
+|---|---|---|
+| the home | `fail`: its Ruby is gone (a Ruby upgrade) or has no samagotchi | `gem install samagotchi` with the new Ruby, then `chi home set` from it |
+| this chi | `warn`: the chi you ran is another Ruby's, or another version, than the home's (`ok` for a source checkout, which starts its own code) | `chi home set` to make this one the home, or run the home's |
+| the last worker boot | `fail`: the newest worker boot in the debug log since the home was set is a `boot_failed` line (the home's Ruby couldn't load chi), not a worker's `start`; nothing without a log file | `gem install samagotchi` with the home's Ruby (or `chi home set` another), then `chi sessions restart ID` |
+| the desktop helper (when installed, and its chi reads this chi's config dir: none with `XDG_CONFIG_HOME` elsewhere) | `fail`: its launch file's Ruby or chi is gone; `warn`: it runs `[ruby, chi]` (installed before the home), boots the home as it was before a `chi home set`, or sets `GEM_HOME`/`GEM_PATH` | `chi desktop install --force` / `chi desktop upgrade` |
+| sessions | `warn`: sessions last saved by a newer chi than the home's (their workers run without what it added) | `chi update` |
+| the tools' `chi` | `warn`: `$XDG_STATE_HOME/samagotchi/bin/chi` boots another chi than the home | the next worker start rewrites it (`chi sessions restart ID` for a running session) |
+| this project's Gemfile.lock | `warn`: the nearest Gemfile.lock up to the git root bundles samagotchi (`bundle exec chi` isn't supported) | `bundle remove samagotchi` there; run chi itself |
+| mise | `ok` with the mise found; without one, `warn` when `session.project_env: mise` is set explicitly (`ok` for the default) | install mise, or `session.project_env: off` |
+| the last worker here | `warn`: the newest worker record for this folder in the debug log is a `project_env` warning (an untrusted mise.toml, a timeout) | `mise trust` there (or fix what it says), then `chi sessions restart ID` |
+
+The rows after the home's first one need a home that can boot chi; the last three are checked with or without one.
+
+**The notice.** An installed chi run by a person at a terminal (stdin and stderr TTYs) on another Ruby, or another
+version, than the home's prints one dim line on stderr, at most once a day: `chi 0.131.0 on /x/bin/ruby; the chi home
+is /y/bin/ruby (chi 0.132.0) (chi home doctor)`. Never inside a session's tools, for `--json`, `--format json`,
+`--non-interactive`, `--version`, `--help`, `chi home`, `chi update` or `chi self`, from a source checkout, or in a
+test run (`SAMAGOTCHI_ENV`, `RACK_ENV`, `CI`). The day is stamped in `$XDG_STATE_HOME/samagotchi/home_noticed`.
+
 ## Project specific description
 
 If an AGENTS.md file is present in the project root, samagotchi injects its
@@ -1504,7 +1532,9 @@ toolkit:
   suggested`, and the turn's first request declares it; the notice reads
   `toolkit: web (suggested, p=0.71) · /toolkit to change`. Anything else (the default, a low-confidence or unknown
   pick, `undecided`, no answer, a failing System 1, which warns once as `[samagotchi:toolkit]`) keeps the default
-  kit. A Stop during the wait (or before it, even with the answer in) ends the turn before its first request, and
+  kit. No answer in time or none at all says so in a warn notice, `toolkit: full (no suggestion: System 1 took over
+  5000 ms) · /toolkit to change` (or `System 1 gave no answer`), and a timeout logs a `toolkit_suggest_timeout`
+  warning: a slow System 1 host wants a larger `guardrails.system_one.timeout_ms`. A Stop during the wait (or before it, even with the answer in) ends the turn before its first request, and
   nothing switches. After an `undecided`, a later prompt within the defer limits may switch the session; that notice
   says `from this turn`, and that request re-reads the whole prompt (system prompt, tools and conversation, which
   the defer limits keep small) without `/toolkit`'s cache confirmation. `/toolkit` or `ctx.use_toolkit` marks the
@@ -1548,6 +1578,18 @@ toolkit:
   `full`. A continue and a fork keep the toolkit name. `/toolkit` shows and changes it. The kit's tools, prompt
   text and group selectors are part of its definition, not the session file: edits reach a saved name at its next
   worker start.
+- **A new web chat: 🧰.** The start page's 🧰 (beside ⚙; a bottom sheet on a phone) picks the new session's toolkit.
+  **Auto**, checked by default, sends nothing: the session is on `toolkit.default` with `toolkit_origin: default`, so
+  with `toolkit.suggest.mode: on` its first message may switch it to a suggested kit. Auto is listed only when that
+  can happen as far as chi web can tell (on mode, a `guardrails.system_one.host`, two described config kits); bundle
+  and memory kits can add candidates it doesn't see. A kit picked is sent as `POST /api/sessions`'s `toolkit` and
+  saved as `chosen`: no suggestion, the default kit included (its row says `default`); without Auto, the default's
+  row is the one checked and sends nothing. The list holds the built-ins and config kits a new session can start
+  on: not `review`, `child` or a kit named `undecided`, not a kit whose `groups:` refuses a new session, and not one
+  that doesn't resolve in chi web (a base that is a bundle kit); bundle and memory kits load in the worker, so pick
+  them with `/toolkit`. The configured default is always listed. A pick closes the list and shows a `tools: lean`
+  chip on the row (a dot on 🧰 on a phone); it is for that create only, never remembered. A review session is
+  always `chosen`: with review files set the list says it starts on the default unless you pick a kit.
 - **Left out: reachable or removed.** A built-in missing from a kit's base list (`lean` has no `delegate`; a
   `kits:` entry on `base: lean` or `child` inherits that) is left out softly: it is **reachable**. `find_tools` searches it as group `chi` (`chi/delegate`, with its inputSchema) beside
   the MCP servers' tools, and `call_tool(tool: "chi/delegate", args: {…})` runs it as `delegate` itself, through the
@@ -1667,14 +1709,18 @@ its own). The first target is a long session such as a day-long coordinator, whe
 - **Set it** at start with `chi --llm-context stale,forget --llm-context-apply turn_end --llm-context-budget 64k`
   (the same flags on `chi send --new`), in the session with `/llm-context strategy … apply … budget …`
   (docs/cli.md, "Session commands"), or from the web's `llm ctx` chip in the info bar.
-- **A new web chat:** the start page's `llm ctx` chip, beside the model picker, shows the picked model's values
-  and follows a model pick. Its form (titled "new session") sets a choice for that one chat: the chip reads
-  `llm ctx stale · new session` in the accent colour, and the create sends it as `POST /api/sessions`'s
-  `llm_context` (`{"strategy": "stale,forget", "apply": "turn_end", "budget": "64k"}`, each a word as
-  `/llm-context` takes it, `default` for unset; anything else answers `400 invalid_llm_context` and starts
-  nothing), so the session file holds it before the first turn runs. It is not remembered: it resets after a
-  create, on a reload and when you open a session (a failed create keeps it), and an untouched chip sends nothing
-  (the model's values apply, as without the chip).
+- **A new web chat:** the start page's ⚙ panel (beside the model picker; a bottom sheet on a phone) holds the new
+  session's rarely used settings, each a row of segments that applies at once: **Thinking** and **Context** (the
+  strategy; **Apply and budget ▸** opens the other two fields, with their own Set), the first segment following the
+  picked model (`default (high)`), and **Review files…** (docs/sessions.md, Review sessions). A row the picked model
+  has no values for is hidden. What is set shows on the row as an accent chip (`think high`, `ctx stale`,
+  `review: README.md`) that opens the panel; on a phone ⚙ carries a dot and its label names them. The create sends
+  the context choice as `POST /api/sessions`'s `llm_context` (`{"strategy": "stale,forget", "apply": "turn_end",
+  "budget": "64k"}`, each a word as `/llm-context` takes it, `default` for unset; anything else answers
+  `400 invalid_llm_context` and starts nothing), so the session file holds it before the first turn runs. Nothing
+  is remembered: the choices reset after a create, on a reload and when you open a session (a failed create keeps
+  them); a choice made before picking a model without that row stays (its chip says it is sent anyway), and nothing
+  set sends nothing (the model's values apply).
 - **Values:** `none` and a budget of `off` are values the session sets on purpose (they win over the model's);
   `default` (or `/llm-context reset` for all three) unsets one, back to following the model. A budget is 4k to
   10M tokens (`4000`–`10000000`, or `4k`–`10000k`). The layers are kept in chi's order (`stale`, then `forget`).
@@ -2042,6 +2088,7 @@ column says so, a `--kebab-name` flag. The maps (`hosts:`, `models:`,
 | `broadcast.threshold` | `0.5` | | The P(yes) a recipient needs, when the triage host gives logprobs; a plain yes or no is 1 or 0. |
 | `session.shared` | `true` | | Plain `chi` runs its session in a worker and attaches; `--no-shared` per run. |
 | `session.idle_exit_minutes` | `30` | yes | An unused worker exits after this; `0` = never. |
+| `session.project_env` | `mise` | | The commands a session's worker runs follow its project: `mise` runs them in the session folder's `mise env`, read once at worker start (`chi sessions restart` picks up a mise.toml edit); `off` doesn't ask mise: the tools keep the env of whoever started the worker (with a chi home, the home's `chi` still goes first on their PATH). See [Project env](sessions.md#project-env). |
 | `session.keep_empty` | `false` | | Keep sessions nothing happened in. |
 | `session.max_children` | `4` | | Running delegated sessions one session may have. |
 | `session.delegate_reports` | `wake` | | When a delegate child ends a turn, its reply reaches the parent: `wake` runs an idle parent's turn for it, `queue` waits for the parent's next turn, `off` leaves it to `delegate_result`. |

data/docs/desktop.md

@@ -300,7 +300,8 @@ exports. So `install` writes `~/Library/Application Support/Chi Helper/launch.js
   whose chi may be found only through them, as under chruby): the home's boot sets its gem path itself, and they
   would reach every command the helper's sessions run (a project's `bundle exec` on the wrong gems). A launch file
   from an older chi loses `RUBYLIB` at the next `chi update`, and `GEM_HOME`/`GEM_PATH` once it boots the chi home
-  (`chi desktop upgrade` moves it to the home);
+  (`chi desktop upgrade` moves it to the home). `chi home doctor` flags a helper that isn't on the home: a
+  `[ruby, chi]` argv, a boot of the home as it was before a `chi home set`, or `GEM_HOME`/`GEM_PATH` in its env;
 - `PATH`: the shell's PATH when the file is written, with only absolute folders, in order, each once. The helper's
   chi, the sessions it starts and their `execute` commands can find the tools your terminal finds (mise, Homebrew,
   `codex`, `node`);

data/docs/guardrails.md

@@ -429,14 +429,50 @@ message:
   get-access-token`, `heroku auth:token`, `kubectl config view --raw`;
   `PairCommand::CREDENTIAL_PRINTERS`). On top of it, a pair turn's `execute` runs
   without every variable whose name matches `KEY|TOKEN|SECRET|PASS|CREDENTIAL|AUTH`
-  (`PairBoundary::SECRET_ENV_NAME`, case-insensitive), and a command still
+  (`PairBoundary::SECRET_ENV_NAME`, case-insensitive) and without the session's
+  project env ([Project env](sessions.md#project-env)); a command that runs
+  `mise` or `direnv` asks the owner (`ENV_LOADER`: they load the project's env
+  files, and `.envrc`, `mise.local.toml` and its kin are secrets like `.env`),
+  and so does a write (by a file tool or a command) to mise's config, its
+  `.tool-versions` included (`MISE_CONFIG`: the owner's next worker start runs
+  its `[env]` and installs what it pins; a command asks when a part of it that
+  names one may write: `rm`, `mv`, `find … -delete` and `find … | xargs rm`
+  do, a read-only part such as `find . -name mise.toml && make` doesn't, the
+  list split at `;`, `&&`, `||` and newlines outside `( … )`; mise's own
+  writes, `mise use`/`mise set`, ask as runs of mise; a config that changes
+  without being named, by `git checkout`, `git stash pop`, `tar x`, `patch` or
+  `cp -r dir/. .`, isn't asked about: the owner's next restart runs it);
+  and a command still
   running at the limit is killed, never handed over as a background task;
-- git settings that make git run a command (`core.hooksPath`,
-  `core.fsmonitor`, `core.sshCommand`, `core.pager`, `core.editor`, a `!`
-  alias) by `git config` or `git -c`, and `git config --global`/`--system`;
+- git config writes, whatever the key (any may make git run a command later
+  in the owner's name: hooks, `core.fsmonitor`, a filter, diff or merge
+  driver, a credential or gpg helper, `hook.<name>.command`, an include): a
+  pair turn's `git config` only reads, parsed strictly
+  (`PairCommand#git_config_read?`: `--get`, `--get-all`, `--get-regexp`,
+  `--get-urlmatch`, `--get-color(bool)`, `-l`/`--list`, `get`, `list` or a lone
+  key, with `--show-origin`, `--show-scope`, `--name-only`, `-z`, `--type=…`,
+  `--default`, `--file F` and the like, every word accounted for; any other
+  option, an abbreviation git would take (`--glob`, `--comm`), a short form
+  (`-t`) or a word too many is a write). Denied too: `git -c`, `--config-env`,
+  a clone's, init's or submodule's `-c`/`--config`, an assignment of
+  `GIT_CONFIG_*` or `GIT_TEMPLATE_DIR`, `git` under an alias, `git config` after
+  `xargs` or in `find -exec`, and an interpreter's script naming `git config`
+  or `git -c`, behind any of git's own options (`--attr-source X`,
+  `--shallow-file X`; one chi doesn't know is read both with and without the
+  next word as its value, `PairCommand.git_command_starts`), and by a
+  builtin's dashed name (`git-config`, `…/git-core/git-submodule foreach`:
+  judged as `git config`, `git submodule`). A command git runs now from its text (`git submodule foreach`,
+  `rebase --exec`, `bisect run`, a `filter-branch` filter, `--upload-pack`,
+  `--receive-pack`, `--extcmd`, an `ext::` URL) is read as a command of its
+  own and asks as an outside write. A `.gitattributes` write isn't asked
+  about: it only selects a driver, and defining one is what's denied;
   and writing git's hooks: a `write` or `edit` of a path in a `.git/hooks`
-  folder (as given or as it resolves), or a command that isn't read-only and
-  names one (`printf … > .git/hooks/pre-commit`, `cp x .git/hooks/`);
+  folder, a submodule's `.git/modules/<name>/hooks` too (as given or as it
+  resolves), or a command whose part that names one isn't read-only
+  (`printf … > .git/hooks/pre-commit`, `cp x .git/hooks/`), and installing
+  them: `git init`/`clone --template`, and the hook installers
+  (`PairCommand::HOOK_INSTALLERS`: `pre-commit install`, `husky`, `lefthook
+  install`, `simple-git-hooks`, `overcommit --install`);
 - running chi, by any wrapper (`bin/chi`, `bundle exec chi`, `ruby … bin/chi`,
   `env … chi`, `watch`, `npx`, `sh -c 'chi …'`, `$(chi …)`), in an assignment's
   value or an alias, a function, after `-exec`/`-c`/`-e`, but `chi --version` and
@@ -476,7 +512,12 @@ message:
 A script a command hands on is read too (`Guardrails::PairCommand`): one a
 shell runs (`sh -c`, `eval`, a heredoc or here-string) as a command of its
 own, one another interpreter runs (`ruby -e`, `python - <<EOF`) by its text
-(chi, secrets, the environment, detaching). A heredoc written as data (`cat`,
+(chi, secrets, the environment, detaching). So is a command handed through a
+variable a program runs through a shell (`PairCommand::COMMAND_ENV`:
+`GIT_EDITOR`, `GIT_SEQUENCE_EDITOR`, `EDITOR`, `VISUAL`, `GIT_EXTERNAL_DIFF`,
+`GIT_SSH_COMMAND`, `GIT_SSH`, `GIT_PROXY_COMMAND`, `GIT_PAGER`, `PAGER`,
+`MANPAGER`, `GIT_ASKPASS`, `SSH_ASKPASS`), as a prefix, `env`'s or `export`'s:
+read as `sh -c` would run it, for the refusals and for an outside write. A heredoc written as data (`cat`,
 `tee`, `git commit -F -`) is not looked into: where it goes is checked. A
 command the checks can't read is refused, never let through on a text match.
 
@@ -496,7 +537,44 @@ rule lowers it), so it comes even in auto mode. A command fails closed
   (`~/oth*`), `git -C`'s folder and the paths in a script it hands on (`sh -c`
   read as a command, `python -c`/`ruby -e`/a heredoc by the paths in its text)
   among them. The program's own word doesn't count (`/usr/bin/sed`), nor does
-  `PATH=…`, nor a message's heredoc (`git commit -m "$(cat <<'EOF' … EOF)"`).
+  `PATH=…`, nor a message's heredoc (`git commit -m "$(cat <<'EOF' … EOF)"`);
+  and it runs no program that writes to its own place outside with no word
+  naming it (`Guardrails::ImplicitWriters`, examples rather than a closed
+  set: `npm`/`pnpm`/`bun`/`deno` global in any spelling (`-g`, `--global=true`,
+  `--location global`, `npm_config_global=true`), `npm`/`yarn`/`bun link`,
+  `npm config set`/`login` (`~/.npmrc`), `yarn global`, `pip install`/`pip
+  config` by any interpreter (`python3.12 -m pip`, `pypy3 -mpip`; with or
+  without `--user`: its site-packages is wherever its Python is; a project
+  venv's `.venv/bin/pip` and `-t`/`--target`/`--prefix` don't count), `uv pip
+  install --system`, `gem install`, `bundle config set` without `--local`,
+  `brew` but its reading verbs, `defaults write`, `cargo install`, `go
+  install`/`go env -w`, `pipx`, `uv tool`/`uv python install`, `dotnet tool
+  install -g`, `corepack enable`, `rustup`/`pyenv`/`rbenv`/`asdf`/`volta`/`nvm`
+  installs and globals, `code --install-extension`, `gh auth`/`config
+  set`/`extension install`, `launchctl` but its reading verbs, `git maintenance register`/`start`, `git
+  lfs install`, `scalar register`/`clone`; a project
+  install such as `npm install` or `bundle install` and build caches don't
+  count), and no shell or interpreter that reads its script from stdin: one
+  on the receiving end of a pipe whatever its options (`… | sh`, `| bash -x`,
+  `| sh -e`, `| python3 -c 'exec(input())'`), `< file`, `bash -s`, `python3 -`,
+  or with no script at all: chi can't see that script. A shell's `-e`, `-x`
+  and `-o …` are flags, only `-c` (or a cluster holding it, `-ec`, `-cx`)
+  hands it a script: the first word after its options (`sh -c -- S`, `bash -c
+  -x S`); an interpreter's own code flag does (`python -c`, `ruby -e`,
+  `node -e`/`-p`/`--eval=`, `perl -e`/`-E`, `php -r`), alone or in a cluster
+  (`ruby -we`, `perl -le`, `node -pe`, `python3 -Ic`, `python3 -c'…'`;
+  `PairCommand.cluster_code_at`: a letter that takes the rest of the word,
+  `ruby -rset`, holds no code). A script file it names (`sh
+  run.sh`, `ruby x.rb`) is not read.
+
+  Accepted gaps (an accident guard for a trusted team): a script file the turn
+  wrote and then runs; inline scripts read only by their text for paths
+  (`find … -exec sh -c '…'`, `flock … sh -c`, `awk 'BEGIN{system(…)}'`,
+  `deno eval`); a `GIT_CONFIG_*` set by `printf -v` or `read` and exported
+  (it affects that command only); a variable outside `COMMAND_ENV` whose
+  value a program runs (`LESSOPEN`, a tool's own `*_EDITOR`); `npx -y`,
+  `npm exec`, `pnpm dlx`, `uvx`: they fetch into a cache, which doesn't count,
+  and run the package as in-project work.
 
 Anything else asks: `rm -rf ~/x`, `sed -i … ~/x`, `curl -o ~/x`, `dd of=~/x`,
 `touch`/`mkdir` outside, `perl -pi … ~/x`, `cd .. && make`, `cd && make`, and
@@ -623,7 +701,8 @@ repo is in count as outside.
 `touches: chi_dirs` (shell tools) matches a command that names a path in chi's
 own folders: the config folder (`config.yml`, `memories/`), the hooks folder,
 the approval store, installed bundles (`memories/.bundles`), the session repo's
-git hooks (`core.hooksPath` honoured) or any `.git/hooks` outside a tmp folder.
+git hooks (`core.hooksPath` honoured) or any `.git/hooks` (a submodule's `.git/modules/<name>/hooks` too)
+outside a tmp folder.
 Each word is read as a path against the folder the command is in by then
 (`cd`, `pushd`/`popd` and `( … )` followed), with `~`, `$HOME` and
 `$XDG_CONFIG_HOME`/`$XDG_STATE_HOME` expanded and symlinks resolved. So
@@ -651,7 +730,9 @@ only `run list|view`, `pr list|view|diff|checks`, `issue list|view` and
 at a word's start), an env prefix, `sh -c`, `xargs`, `eval`, `sudo` and the
 like make a command not read-only, as does a `task_create` `env:` that sets `BASH_ENV`, `ENV`, `CDPATH`, `IFS`,
 `SHELLOPTS`, `BASHOPTS`, `BASH_FUNC_…`, `LD_PRELOAD`, `LD_AUDIT`, `DYLD_INSERT_LIBRARIES`, `GIT_EXTERNAL_DIFF`,
-`GIT_CONFIG_PARAMETERS` or `GIT_CONFIG_COUNT` (they change what its words run; `PATH` doesn't count). It errs
+or a git config variable (`GIT_CONFIG`, `GIT_CONFIG_GLOBAL`, `GIT_CONFIG_SYSTEM`, `GIT_CONFIG_PARAMETERS`,
+`GIT_CONFIG_COUNT`, `GIT_CONFIG_KEY_n`/`VALUE_n`: `ShellGitDirs::CONFIG_ENV`) (they change what its words run; `PATH`
+doesn't count; a pair turn's command that assigns a git config variable is denied like `git -c`). It errs
 towards asking.
 
 A tool name may be a glob, so one rule covers a plugin's tools (an MCP server's,
@@ -1055,8 +1136,22 @@ gate below passes, in this order:
    it knew the dir: a script or heredoc body (`python3 -c '…'`, `cat >> x.md
    <<'EOF'`), a phrase (`echo "- a note"`) or a glob with no `/`. So
    `cd memories; cd ..`, `cd "${PWD%/*}"`, `cd $(dirname $PWD)` or `cd -`
-   loses the exemption, and the memories text then refuses it. A script body
-   is not looked into beyond its text: an accident guard, not containment.
+   loses the exemption, and the memories text then refuses it. So does a
+   script a shell or interpreter runs that climbs by its own calls
+   (`SelfProtect::SCRIPT_CLIMB`: `os.pardir`, `dirname`, `chdir`, `Dir.pwd`,
+   `Path.parent`, `rindex`, a slice from the end), and one chi can't see: a
+   script file (`cd memories && python3 x.py`) or stdin (`… | python3`,
+   `sh < f`, any interpreter or shell a pipe feeds, `| sh -x` too), by any
+   version's name (`python3.12`, `pypy3`, `Rscript`, `tclsh`), or a program
+   that runs a file (`SelfProtect::FILE_RUNNERS`: `make`, `rake`, `awk -f`,
+   `deno run`, `npm run`). A heredoc only written (`cat >> x.md <<'EOF'`) is
+   data whatever it says. A script body is not looked into beyond its text:
+   an accident guard, not containment (a script can build a path some other
+   way: `p.replace("memories", "config.yml")`, `p[0:len(p)-8]`, `.sub`,
+   `.slice` aren't caught). The price is some harmless commands the user now
+   answers: `python3 scripts/lint.py <memories>/notes.md`, `cat notes.md |
+   python3 -c …` from the memories folder, a climb word written as data by a
+   script (`File.write(".../notes.md", "dirname")`).
    A protected rule
    (`Verdict::PROTECTED_RULES`) may be listed by name and System 1 may answer
    it, but a call that really writes config.yml or the hooks is refused here;

data/docs/internals/background-tasks.md

@@ -45,6 +45,7 @@ Behavior:
 - `execute` and `task_create` both spawn with chi's own Ruby/Bundler setup scrubbed (`TaskRuntime.sanitized_spawn_env`): `RUBYOPT` loses its `-r…bundler/setup` flags (others stay) and `RUBYLIB`, `BUNDLE_GEMFILE`, `BUNDLE_BIN_PATH`, `BUNDLER_VERSION` are unset, so a project's `ruby -e` or `bundle exec` uses its own Gemfile when chi runs under `bundle exec`. `task_create` refuses those keys in the model's `env`; `execute`'s `env` comes from chi's callers (`Builtins`, `!cmd`), not the model, and is set over the scrub. An `execute` handed over at its limit keeps the process it spawned, so the task runs with the same env.
 - `execute` and `task_create` export chi's own markers into the command, set over the model's `env` (which can't set them: `Error: env key is reserved`): `SAMAGOTCHI_PARENT_SESSION` (the session's id, `chi` without one; a chi started there answers as a parent agent), `SAMAGOTCHI_SESSION_MODEL` (the resolved ref the session runs on, read at each call so it follows `/model`; unset when unknown) `SAMAGOTCHI_SESSION_THINKING` (the session's own thinking level; unset when it has none) and `SAMAGOTCHI_SESSION_REASONING_HISTORY` (its own reasoning_history level, the same way). `chi self` reads the last three for its model, thinking level and reasoning history. The four are `ChildEnv::SESSION_MARKERS` (`TaskRuntime::MARKER_ENV_KEYS`), which a spawned worker unsets (`ChildEnv.unset`, merged into its spawn env). A session's worker never inherits them from whoever started it (a `chi send` run by another session's `execute`): its other commands (a user's `!cmd`, an MCP server, a context command) have none.
 - They also pass on a set `XDG_STATE_HOME` / `XDG_CONFIG_HOME` made absolute (`Builtins.xdg_absolute`, via `Paths`), so a chi the command runs in another `cwd` (`chi send`) reads this chi's state and config. These aren't reserved: an XDG dir the model sets in `task_create`'s `env` stays its own.
+- Every runner starts from the session's project env, `ProjectEnv.tools_env`: the overlay a spawned worker computed once at boot (`SessionManager.apply_project_env` → `ProjectEnv.compute` → `ProjectEnv.install!`; its folder's `mise env`, and the chi shim's dir first on PATH so `chi` is the chi home's), less `ProjectEnv::TOOLS_DROP` (`RUBYOPT`, `RUBYLIB`, Bundler's: the scrub above sets those). Outside a worker (`ProjectEnv::NONE`) it is `{}`. The sites: `execute` and `task_create` (`Tools::Builtins#project_env`, under the markers and the model's `env`; a participant's turn gets `{}`), the user's `!cmd` (`SessionCommands#shell`) and a context source's command (`ContextFetch#env_for`). MCP servers take `ProjectEnv.current.env` whole under the server's own keys (`bundles/mcp/plugin.rb` `server_env`: no `TOOLS_DROP`, no participant rule). chi's own process env is never changed, and the project env never enters the prompt. User docs: [Project env](../sessions.md#project-env); the launch side: [How chi launches itself](../architecture.md#how-chi-launches-itself).
 
 ## Finish wake