@with-logic/elwood 0.2.1 → 0.2.2

package/docs/cli-behavior.md

@@ -55,8 +55,28 @@ invalid and will conclude the hook "never fires". (This once produced a false
 sandboxed homes, and user `config.toml` hooks merge additively with `-c` hooks.)
 Because `SessionStart` is Elwood's authoritative Codex readiness signal
 (`markInitialReadyFromHook`, `src/codex/session/hooks.ts`), cold-start readiness
-comes from that hook, bounded by a **10 s starvation deadline** armed on the
-first render frame (`src/runtime/readiness/initial-ready.ts`, `maxWaitMs = 10_000`). C-API-28.
+comes from that hook, bounded by a **two-stage starvation deadline** armed on the
+first render frame (`src/runtime/readiness/initial-ready.ts`): after 10 s
+(`initialDeadlineMs`) Codex readiness waits for a configured composer, described
+below, and after 60 s (`initialBackstopMs`) it is released without one. C-API-28.
+
+**Codex 0.164 paints a boot composer before its session is configured
+(2026-10-25).** About 0.6 s after its first output Codex draws `› Ask Codex to do
+anything` and `? for shortcuts` with no model footer; the header may read
+`loading` or already show the path. The model footer (`GPT-6.1-Sol default ·
+<path>`) appears only once the session is configured, which for an untrusted
+folder is after the directory-trust gate is answered. On a loaded machine (load
+average 20 to 127, 8 concurrent launches with `autotrust`, fresh `git init`
+folders) the gate painted 11.1 to 30.6 s after the first output in 24 of 32
+launches, and every one of those 24 reported `ready` at 10.0 s, onto a screen
+showing the boot composer without a footer. The other 8 painted their gate at
+8.9 to 9.0 s and readied after it, on footed composers. Unloaded, the gate came
+3.4 to 3.9 s after the first output. Codex's deadline therefore marks only onto a
+composer with its model footer (`codexComposerConfigured`,
+`src/codex/screen/clearance.ts`), and a 60 s backstop, twice the longest measured
+gate delay, releases readiness if no footer is ever recognized; a gate painting
+later than that would still follow `ready`. Fixtures:
+`tests/fixtures/codex-0.164.0/boot/`. C-API-28.
 
 **Codex 0.153.3 can still swallow the deadline-released first paste under load.**
 Its cold composer may accept the paste visually, repaint another startup spinner,
@@ -119,6 +139,38 @@ misattributed to a CLI regression.)
   quiet frame is not proof it finished. Evidence-driven turns (a caller
   submission, a hook) bypass settling immediately. `src/core/turn-state.ts`,
   C-TURN-03.
+- **Codex 0.164.0 paints a `Resuming session…` placeholder before it loads the
+  conversation (2026-10-25).** Five captured resumes in private Codex homes, at load
+  averages of 20 to 60, all had the same shape. First comes the header, then
+  `Resuming session…`, then the live composer and `? for shortcuts`. That frame
+  repaints 8 to 11 times with no visible change. Elwood latches resume readiness on
+  its first composer frame. 0.5 to 1.6 s later, Codex sets a braille title spinner
+  and `OSC 7501;state=working:app=codex`. It replaces the placeholder with the
+  replayed transcript, either in the spinner's first frame or one frame later. The
+  spinner runs 0.7 to 1.5 s. Then the title goes idle with `state=idle`, at most one
+  cursor repaint follows, and Codex sends nothing more until input arrives. The quiet streak counted the
+  placeholder's repaints and released settling before the load. The spinner then
+  became a phantom `running → ready` on every capture. The real-CLI e2e reported it
+  as `saw: running,ready`. Placeholder frames are no longer quiet. Once the
+  placeholder has painted and the load's spinner has been seen, the first quiet
+  composer ends settling. A five-frame streak never arrives from an idle Codex.
+  Captures: `tests/fixtures/codex-0.164.0/resume/`. C-TURN-03.
+- **Codex records a turn's completion only after its `Stop` hook returns
+  (2026-10-25).** Elwood reports `ready` from that hook, so a host that stops the
+  session at that `ready` signals Codex 0.164.0 before it writes the turn's
+  `task_complete`, and Codex exits without it. Stopping in the `ready` listener lost
+  the record in 3 of 3 probe runs and in 2 of 2 runs of
+  `tests/e2e/codex-stop-commit.e2e.ts` on `main`. Stopping 66 ms later lost it too;
+  at 156 ms and at 1 s it was written. The record carries the hook's `turn_id`, and
+  its own timestamp falls 3 to 94 ms after the hook reached Elwood. Resuming such a
+  conversation replays it ending in
+  `■ Conversation interrupted - use /feedback if something went wrong`. Before the
+  placeholder fix, that banner closed the spinner's phantom turn early and a second
+  phantom followed: `saw: running,ready,running,ready`. The `uncommitted-turn`
+  capture retains that replay. `stop()` and `teardown()` now give Codex up to 2 s to
+  write the record before signaling it. With the wait, a stop at `ready` took 70 to 126 ms
+  instead of 13 to 29 ms, and the record was always written.
+  `src/codex/session/turn-commit.ts`, C-TURN-03, C-LIFE-13.
 - **A caller submission can precede the resumed composer's repaint.** The old
   idle composer may remain visible briefly after `caller_submitted`; that frame
   is not a turn end. Resume settling now synchronizes to current rendered work
@@ -143,6 +195,23 @@ misattributed to a CLI regression.)
   observed `◐ ` prefix alongside the existing braille range; both screen facts
   and live trust clearance share it. No other new spinner glyph is inferred.
   C-TURN-05, C-TRUST-01.
+- **Claude 2.1.310 alternates its working title between `◐` and `◑`, and its
+  spinner row has no `esc to interrupt`.** Sampling the title every 50 ms through
+  real turns (2026-10-25, Opus 5.5, 189 columns) gave `✳ ◐ ◑ ◐ ✳` and
+  `✳ ◐ ◑ ◐ ◑ ◐ ✳`, each half circle lasting about a second, with `✳` while idle.
+  The spinner row reads `✢ Nebulizing… (2s)`, or
+  `✶ Computing… (running Stop hook · 8s · ↓ 3 tokens)`, and no frame of those turns
+  contained `esc to interrupt`, so the title was the only working signal. With only
+  `◐` recognized, every `◑` frame read as idle: the session reported
+  `running → ready → running` about once a second for the whole turn, eight false
+  `ready`s during one 6 s `sleep` tool call. The ergonomic turn treats an accepted
+  `ready` as the start of its 2 s quiet window, so a turn with more than 2 s between
+  a `◑` frame and its first text settled early. Six concurrent `send("Reply with
+  exactly OK…")` calls returned `""` in 5 of 6 at load 117 and 6 of 6 at load 207,
+  with Claude's `Stop` carrying `OK` 2–4 s later. Both half circles now read as
+  working (`tests/fixtures/claude-2.1.310/working-half-right.txt`): the same six
+  sends returned `OK` 6 of 6 at load 120–126 with no `ready` before `Stop`.
+  C-TURN-05, C-API-48.
 - Both CLIs render the literal `esc to interrupt` only while a turn is running
   (Claude footer, Codex "Working" spinner). Elwood's `TurnStateWatcher` keys off
   this, and **arms only after initial readiness** because the Codex MCP boot
@@ -159,6 +228,64 @@ misattributed to a CLI regression.)
   after done — do not treat spinner presence as a reliable per-frame liveness bit
   at tiny sizes.
 
+## Rejected turns (2026-10-25)
+
+**Claude 2.1.310 ends a rejected turn with `StopFailure`, never `Stop`.** A bogus
+`--model elwood-bogus-model` is refused before any model quota is consumed. The
+hooks were `InstructionsLoaded`, `SessionStart` (`model: "elwood-bogus-model"`),
+`UserPromptSubmit`, then `StopFailure` with `error: "model_not_found"`, a
+`prompt_id` matching the submit, and `last_assistant_message` set to Claude's own
+"There's an issue with the selected model (elwood-bogus-model)…" text. No `Stop`
+fired. The transcript writes that same text as an `assistant` entry carrying
+`isApiErrorMessage: true`, `error: "model_not_found"` and `message.model:
+"<synthetic>"`, so Elwood's transcript activity surfaces it as an ordinary
+`assistant_message`. Startup also shows `⚠ Model "elwood-bogus-model" isn't
+recognized`, so the session reaches ready normally. Before C-API-59 the
+no-oracle quiet window settled that turn as a success: `ClaudeSession.send`
+resolved with the error text and `elwood run` exited 0 with it as `response`.
+Elwood now reads `StopFailure` as rejection evidence (`claudeBoundarySignal`) and
+fails the turn with `turn_failed`, message `Claude rejected the turn:
+model_not_found`. The assistant text is not the diagnostic (§6.1). C-API-59,
+C-CLI-28, C-E2E-20.
+
+**The hook can lag the first rendered `ready` under load.** On an idle machine
+`StopFailure` arrived in the same 0.1 s as `ready` and 0.3 s before the transcript
+entry. With four concurrent sessions at load ~55, it lagged the first `ready` by
+0.8, 2.0, 2.5 and 1.8 s. One run rendered a transient `ready → running → ready`
+before the hook. The turn fails only if the hook arrives before the turn settles,
+and a no-oracle turn settles 2 s after its last content. That is the same lag
+that can end a successful turn early when its `Stop` is late. A hook that late can
+also land while the NEXT turn is running. Each hook is delivered by its own bridge
+process, so the next turn's `UserPromptSubmit` can even arrive first. Elwood
+therefore applies a `StopFailure` only after the turn's own `UserPromptSubmit`, and
+only when its `prompt_id` matches that submit's.
+
+**Codex 0.164.0 rejects the same bogus model without any boundary hook.** In a
+sandboxed `CODEX_HOME`, only `SessionStart` and `UserPromptSubmit` fired. The
+evidence is a transcript `event_msg` `task_complete` carrying `error`, with
+`last_agent_message: null`, as first measured on 0.155.0. The record's `turn_id`
+(and `root_turn_id`) equal the `UserPromptSubmit` `turn_id`. `error.message` is the
+service's raw JSON body (`{"type":"error","status":400,"error":{...,"code":
+"model_not_found"}}`, "…model is not supported when using Codex with a ChatGPT
+account."), and `error.codex_error_info` is `"other"`. The binary's
+`CodexErrorInfo` kinds are bare strings (`usage_limit_exceeded`, `bad_request`,
+`other`, …) or one-key objects for kinds with fields (`http_connection_failed`,
+`response_stream_connection_failed`, `response_stream_disconnected`, …). The
+screen still reached `ready` 1.4 s after the submit hook and 0.15 s before the record.
+
+On 0.164.0 the turn binds the submit's `turn_id`, and only a private `Stop` or a
+classified rendered completion ends it. A rejected turn has no `Stop`, so its end
+depended on the rendered path. In the A/B runs (load 60–100), `CodexSession.send`
+resolved `""` about 20 s after submission, and `elwood run` exited 0 with
+`"response": ""`, the same empty success 0.155.0 showed. In one earlier probe, run
+beside a full test suite at load ~100, `send` stayed pending for over five minutes
+and resolved `""` only when the CLI was killed. Elwood now
+reads a failed `task_complete` that names the accepted `turn_id` as that turn's
+native boundary (`confirmCodexRejection`) and fails it with `turn_failed`. The
+message is `error.message` and `details.agentError` is the `codex_error_info`
+kind. A second turn on the same session is rejected the same way, so the first
+released the session at its real boundary. C-API-60, C-CLI-28, C-E2E-21.
+
 ## Codex transcript replies
 
 **Codex 0.149.1 writes committed replies as phased `message` response items, not
@@ -181,6 +308,127 @@ only their raw observation. C-CODEX-16, C-CODEX-22.
   visible catalog; every returned row correctly had `isCurrent: false`.
   Real picker tests should let the installed CLI choose its launch default,
   rather than pinning a model that can disappear from the catalog.
+- **Codex 0.164.0 marks only the `(current)` row; nothing on screen names the
+  default.** Probed 2026-10-25 in a sandboxed `CODEX_HOME` whose config sets
+  `model = "gpt-6.1-sol"`, with the session launched on `--model gpt-6-luna`: the
+  picker drew `› 4. GPT-6-Luna (current)` and no marker on GPT-6.1-Sol. A session
+  switch moves `(current)` to the new row, again with nothing on the launch model.
+  Older Codex drew `1. gpt-5.5 (default)` beside `2. gpt-5.4 (current)`
+  (`codexPickerSplitMarkers`), so reading "a lone `(current)` row is also the
+  default" reported the session's own model as the user's default. Elwood now reads
+  the default from `config.toml`. The cached catalog (`models_cache.json`) carries
+  no default flag, so Codex's built-in default in an unconfigured home cannot be
+  identified at all.
+- **Claude scrolls a list longer than ten rows inside the picker (2.1.310, 2026-10-24).**
+  An account with 13 models renders a ten-row window. At the top, rows 1–9 are plain,
+  row 10 is `↓ 10. Opus 4.8 …`, and `… +3 models` stands directly under it. Moving the
+  cursor past the last visible row scrolls the window by one: the first visible row then
+  carries `↑` (`↑ 2.`), and the last carries `↓` with `… +2 models` / `… +1 model` below it
+  while any rows stay hidden; at the end of the list that line is blank. The cursor glyph
+  REPLACES a marker on its row (`❯ 11. Opus 4.7` above `… +2 models`), and moving up keeps
+  one row visible above the cursor, so arrowing from row 5 to row 4 shifts the window from
+  `↑ 4.`–`13.` to `↑ 3.`–`↓ 12.`. The picker OPENS scrolled when the current model is below
+  the fold: started on `claude-opus-4-6`, it showed `↑ 3.` through `❯ 12. Opus 4.6 ✔` and
+  `… +1 model`, with the `Default (recommended)` row out of view. Two consequences: the
+  region grammar must accept a block that starts at its `↑` row and ends at its `↓` row or
+  overflow line (before this, it rejected every frame of such a list, so `setModel` failed
+  on its first arrow key with "The model picker was replaced"), and `setModel` must settle
+  on the cursor row's identity, not its index, because a target's index changes as the
+  window scrolls under the cursor. Fixtures:
+  `tests/fixtures/claude-2.1.310/model-picker/`. C-API-23, C-API-24.
+- **Arrow keys walk Claude's picker window without applying anything (2.1.310, 2026-10-25).**
+  Row numbers are absolute positions, so a window starting past row 1 hides the rows
+  above it and `… +K models` counts the rows below; `listModels` reads the whole list by
+  walking the cursor one row at a time and merging the windows by number. Measured on a
+  13-model account: the window scrolls DOWN only once the cursor passes its last row, keeping
+  the cursor ON the last visible row (`↑ 2.` … `❯ 11.`), but scrolls UP while one row is
+  still above the cursor (`↑ 3.` `❯ 4.`), so the cursor never sits on the first row of a
+  scrolled window. Both ends WRAP: `↓` on row 13 jumps to `❯ 1.` with the top window, and
+  `↑` on row 1 jumps to `❯ 13.` with `↑ 4.`–`13.`; Elwood never presses past an end. Opened
+  at the top, 12 `↓` reveal rows 11–13; opened scrolled on row 12, one `↓` and 11 `↑`
+  reveal rows 13, 2, and 1. After 28 arrow presses, Escape printed `⎿ Kept model as Opus
+  5.5 (default)`, the header kept `with xhigh effort`, and the reopened picker showed the
+  same current row and effort, even though the effort row had followed the highlight
+  (`◐`, `●`, `○ Effort not supported`) on the way. A session started with `--name` adds a
+  rule carrying the name above the picker and walks identically. Fixtures:
+  `walk-down-from-top.txt`, `walk-opened-scrolled.txt` (frames separated by `--- ↓`/`--- ↑`,
+  each the screen after that key). A move that scrolls the window can be read before its
+  overflow line is repainted: a real listing that read on every render (2026-10-25) read
+  the move to `❯ 11.` with a `… +K models` count that was missing or did not add up to 13,
+  so the walk waits for a frame whose count adds up instead of failing on that one.
+  The raw stream shows why: the renderer writes only the cells that change, top to bottom,
+  and the PTY delivers the paint in reads of about 1 KB, so a frame can be read between
+  two reads. Scrolling to row 11 arrived as a 1,020-byte read carrying the new rows and a
+  71-byte read carrying the `3`→`2` of the count. The opening paint is ordered the same way:
+  the `… +K models` line is written before the effort row and the footer, and Elwood reads
+  the picker as complete only once its `Esc to cancel` footer is on screen, so a complete
+  frame always carries its count. Replaying every byte prefix of two real listings (opened
+  on row 2 and walked to 13; opened on row 10, where a count-less frame would read as a
+  complete ten-row list) found no complete frame stating fewer than 13 rows; the only
+  inconsistent ones were the stale-count frames above (`claude-picker-paint-order.test.ts`
+  pins the row-10 opening, `opening-on-row-10.json`, captured paint bytes over a placeholder
+  screen). If a later Claude painted the footer before the count, the walk could take a
+  full window with the cursor on its last row for the whole list: a listing would come back
+  short, and `setModel` would reject a hidden id as unknown. No key would go anywhere else,
+  since every key is still gated on the operation's own complete picker. C-API-23, C-API-24.
+- **The picker's effort row follows the HIGHLIGHTED model, and `●` is one of its glyphs.**
+  On 2.1.310 the row under the list reads `○ Low effort`, `◐ Medium effort`, `● High
+  effort`, `◉ xHigh effort`, or `◈ Max effort` (each `←/→ to adjust`, with `(default)` when
+  it is that model's default), and `○ Effort not supported for Haiku 4.5` for a model
+  without effort. It changes as the cursor moves, so navigation crosses several glyphs.
+  `●` is also the older Claude reply bullet, which the region grammar treats as foreign
+  content, so the control row is recognized by its own copy before the reply check;
+  otherwise every frame with the cursor on a High-effort model reads as transcript. Captured
+  with `--effort low|medium|high|max` across all 13 rows. C-API-24.
+- **Claude paints `/model` over its slash-command menu, so the header lands first.** A
+  5 ms capture on 2.1.310 (2026-10-24) showed the `Select model` header for 10–500 ms above
+  a partial dialog: rows 1–3 with row 3 spliced into a stale `/review-…` suggestion and
+  the rest of the menu below it, rows 1–7 the same way, or all ten rows and the overflow
+  line above leftover menu prose and no footer yet. Parsing the first frame that showed
+  the header returned one row, three rows, or none (`listClaudeModels` in `~/.coal-harbor`
+  gave 9, 1, error, 9, error over five runs), and Coal Harbor persisted a one-row
+  `default` catalog as a successful discovery. The picker is therefore parsed only once
+  the region grammar recognizes the complete dialog, footer included — the same check
+  every key write passes. A picker that never completes is never written to, because a
+  bare header is untrusted (the agent can print one): the operation fails, and failure
+  cleanup Escapes the dialog once it is recognizable. Cleanup's release is not proof the
+  picker is gone either: a blank or half-painted frame matches neither grammar, and the
+  picker can paint again after it. So once the operation or its cleanup has seen its
+  dialog, or while the picker header is up, a cleanup that ends on anything short of a
+  positively clear composer keeps queued input held until the composer is clear: Enter on
+  that picker would apply its highlighted row. Only a dialog the caller owns replacing it,
+  a complete `PreModelSwitch` hook confirmation, ends that hold early; the hook's prompt is
+  left for the caller. The header only ever holds; it never authorizes a key. Fixtures: `tests/fixtures/claude-2.1.310/model-picker/painting-*`.
+  C-API-23, C-API-24, C-API-55.
+- **Claude can list a compiled five-row picker instead of the served catalog (2.1.310,
+  2026-10-25).** Observed: launched with `CLAUDE_CODE_MODEL_CATALOG=0`, the picker lists
+  `1. Default (recommended)`, `2. Opus`, `3. Fable`, `4. Sonnet`, and `5. Haiku`. Those are
+  bare family names with no version, and there is no overflow line. Every listing in that
+  process returns the same five rows, and Elwood reads them correctly. A listing e2e on a
+  loaded machine got the same five rows for its whole session, with no catalog variable in
+  its environment (the e2e harness strips `CLAUDE_CODE_*`).
+
+  From the 2.1.310 bundle, not observed: the choice is made once per process. The catalog
+  is off when `CLAUDE_CODE_MODEL_CATALOG` is falsy, under `--bare`, with nonessential
+  traffic disabled, with `ANTHROPIC_UNIX_SOCKET` set, with a provider that is not
+  first-party, with auth that has no catalog scope, when policy disallows
+  `allow_model_catalog`, or when the `tengu_delegated_quail` flag is off. With no catalog
+  cached in `~/.claude/cache/model-catalog/`, a first fetch slower than 1,750 ms (1,500
+  headless) also falls back.
+
+  The fallback has no hidden rows, so the listing e2e can't test the window walk against
+  it. Instead of retrying, the e2e fails with these causes
+  (`tests/e2e/claude-compiled-fallback.ts`), so a degraded environment stays visible.
+  C-API-23.
+- **Codex 0.164.0 shortened its dialog hints.** The picker closes with `enter select ·
+  esc back` and the reasoning screen with `enter default · s session · esc back` (one
+  Escape still returns to the picker). Neither matched the old closing-hint phrases
+  (`esc to cancel`, `esc to go back`), so the grammar never recognized either dialog:
+  `setModel` failed on its first key with "The model picker was replaced", and only the
+  header-parsing `listModels` kept working. Each CLI now supplies its own hint phrase,
+  so Claude's `Esc to cancel` no longer closes a Codex dialog either. The new `s session`
+  key is a session-only apply. Fixtures: `tests/fixtures/codex-0.164.0/model-picker/`.
+  C-API-23, C-API-24.
 - **A model dialog replaces the composer; nothing renders below it.** Full-viewport
   captures from Claude 2.1.274 and Codex 0.154.0 (2026-09-17,
   `tests/helpers/model-dialog-viewports.ts`) show the picker, Codex's reasoning
@@ -197,12 +445,14 @@ only their raw observation. C-CODEX-16, C-CODEX-22.
   phrase on a reply or composer row itself (`❯ Select model` is staged input), and
   a quoted picker above another dialog. Below its header a native dialog holds
   exactly one contiguous block of picker rows (description column, numbered from 1,
-  at most one cursor); any other caret or numbered row (`❯ 1. Yes`, `  1. Yes`, a
-  staged `❯ 1. fix this  then that`) restarts the numbering, follows the blank or
-  rule that separates the composer, or lacks the column, and marks the region as
-  someone else's. The block must also be COMPLETE before Elwood treats it as live:
-  every captured picker and reasoning screen carries at least two numbered rows and
-  a closing hint row (`Esc to cancel`, `esc to go back`). A header with neither —
+  at most one cursor); the one exception is a scrolled Claude window, which starts at
+  its `↑`-marked row (see the windowed list below). Any other caret or numbered row
+  (`❯ 1. Yes`, `  1. Yes`, a staged `❯ 1. fix this  then that`) restarts the
+  numbering, follows the blank or rule that separates the composer, or lacks the
+  column, and marks the region as someone else's. The block must also be COMPLETE
+  before Elwood treats it as live: every captured picker and reasoning screen carries
+  at least two numbered rows and a closing hint row (`Esc to cancel`, `esc to go
+  back`, `esc back`). A header with neither —
   a transcript quoting `Select model` above a trust or hook prompt, or above a
   reply's own numbered list — is a fragment, and Escaping it would dismiss the live
   prompt underneath. The CURSOR is deliberately not required: a complete picker
@@ -281,6 +531,45 @@ only their raw observation. C-CODEX-16, C-CODEX-22.
   the returned composer. C-API-24, C-ATTN-04. Verified from the installed 2.1.258
   native binary and field-captured model/effort dialogs.
 
+## Login-shell `CODEX_HOME` (2026-10-25)
+
+Codex runs as `$SHELL -l -i -c 'exec codex …'` (§4.2). The login shell inherits
+Elwood's environment and the user's startup files can change it, so what decides
+which `config.toml` Codex reads and the picker writes is the environment after
+those files run, not Elwood's own.
+Codex takes a non-empty `CODEX_HOME`, canonicalized (a relative one from the
+directory it runs in), else `$HOME/.codex`. Startup files can make that answer
+depend on the launch itself:
+
+- **`$PWD`.** The login shell starts in the session `cwd`, so
+  `export CODEX_HOME="$PWD/codex-home"` gives every project its own home. Real Codex
+  0.164.0 in two projects under that profile kept each project's default and restore
+  in that project's home.
+- **The terminal and the session's environment.** Only the PTY launch has a TTY on
+  stdin and `ELWOOD_SESSION_ID`. A second shell started to ask (the first version of
+  this fix ran `printf` in a separate login shell) has neither, so a profile that
+  branches on `[[ -t 0 ]]` or on a session variable answers for a different home. The
+  real e2e's profile exports the session home only when both are present.
+- **Exported values only.** Codex sees only exported variables. A profile that
+  assigns `CODEX_HOME=…` without `export` changes what Codex sees only if the
+  variable was already exported, for example inherited from Elwood's environment.
+  Otherwise Codex keeps the inherited value, or none. The report is written by a
+  child `/bin/sh`, which sees exactly what `codex` inherits.
+- **A symlinked `cwd`.** The kernel follows a symlink before a later `..`, and so
+  does Codex. From `feature-link -> worktrees/feature`, real Codex 0.164.0 with
+  `CODEX_HOME=../codex-home` ran with `worktrees/codex-home`: its picker wrote that
+  file, not the `codex-home` beside the link. Resolving the value by name against
+  the session `cwd` read and restored the wrong file.
+
+Elwood therefore has the launch script write the answer just before `exec codex`:
+`/bin/sh -c 'printf "%s\0%s\0%s\0" "$CODEX_HOME" "$HOME" "$PWD"' > <report> || exit 73; exec codex …`,
+with the report in the session's socket home, named after the launch's socket. The
+session canonicalizes a non-empty home with `realpath` on the unnormalized
+`$PWD/$CODEX_HOME`, which follows links the way the kernel does. Profile output
+(banners, `nvm` notices) goes to the terminal, never to the report, so nothing has to
+be parsed out of shell noise. If the report cannot be written, the launch shell exits
+with 73 and never starts Codex. C-CODEX-24.
+
 ## Trust prompts
 
 The real Claude folder-trust prompt renders as **one dialog** spanning header →
@@ -290,8 +579,10 @@ across physical rows** on a narrow terminal. Its option format is version-couple
 - Claude 2.1.206 used numbered rows with the affirmative first
   (`❯ 1. Yes, I trust this folder / 2. No, exit`).
 - Claude 2.1.252 uses unnumbered cursor rows with the safe decline selected first
-  (`❯ No, exit / Yes, I trust this folder`). Accepting requires ArrowDown + Enter;
-  sending the old numeric answer leaves the dialog waiting.
+  (`❯ No, exit / Yes, I trust this folder`). Accepting requires moving the cursor
+  to the affirmative and pressing Enter; sending the old numeric answer leaves the
+  dialog waiting. From 2.1.310 evidence, never do that with a relative arrow and a
+  separate Enter (see "Claude trust selection reset" below).
 
 The workspace gate is independent of tool permission policy: it still appears
 under both `--permission-mode bypassPermissions` and the exact
@@ -304,7 +595,8 @@ under both `--permission-mode bypassPermissions` and the exact
   "Yes" option) must never anchor a prompt (anti-spoofing).
 - treat the whole numbered or cursor-selectable block as the option region,
   including unselected rows above the cursor, then either send the old option
-  number or navigate from the rendered cursor to the affirmative and press Enter.
+  number or select the affirmative by its absolute row and confirm in the same
+  write.
 
 Under `autotrust`, detect-and-approve: if a trust prompt is detected, answer yes
 rather than leave the agent hanging on the gate. Keep the cheap safety: never
@@ -326,6 +618,45 @@ cover both `autotrust` settings. A native rerun with this grammar answered the g
 and attached the first image; its later cancelled-draft cleanup failed separately,
 so this is trust/attachment evidence, not a passing successor-cleanup run. C-TRUST-01.
 
+**Codex 0.164.0 asked for folder trust only in a Git repository, and saved the answer to
+`CODEX_HOME`.** Real launches on 2026-10-25, each with a fresh `CODEX_HOME`: in a plain
+scratch directory, Codex reached `ready` and wrote no trust entry, with and without
+`--sandbox read-only --ask-for-approval never` and with and without a seeded
+`config.toml`; no trust gate rendered in the launches whose screens were captured. After
+`git init` in the same kind of directory it showed `Folder access` with `Note: You’re in
+a subdirectory of a Git project. Trusting will apply to the repository root:` and the
+resolved path (`/private/var/...` for a `/var/...` cwd). `Trust and continue` then saved
+`[projects."<that path>"]` with `trust_level = "trusted"` to `$CODEX_HOME/config.toml`.
+Every launch also wrote `[tui] screen_reader_detection_done = true` there, plus state
+and log databases, a models cache, and plugin and skill caches. An e2e that leaves
+`CODEX_HOME` unset therefore writes into the developer's own `~/.codex`, so the suite
+gives every process a private one (`tests/e2e/codex-home.ts`, C-E2E-22).
+
+**Codex 0.164.0 draws its trust gates differently when hook trust is not bypassed
+(2026-10-25).** Native launches at 100 × 40 in a `git init` scratch directory with a
+fresh `CODEX_HOME`:
+
+- With `--dangerously-bypass-hook-trust` or `-c hookTrust="trust-all"` (Elwood passes
+  one of them on every launch, `src/codex/command.ts`), the `Folder access` gate is the
+  0.156.1 layout: `1. Trust and continue`, `2. Quit`, and `enter continue · esc quit`.
+  No hook gate follows.
+- With neither, as C-E2E-09 launches Codex to see both gates, the same gate's decline
+  reads `2. Back to Agent Command Center` and its footer is `enter continue · esc back`.
+  After `Trust and continue`, `Hooks need review` follows with `1 hook is new or
+  changed.`, `Hooks can run outside the sandbox after you trust them.`, `1. Review
+  hooks`, `2. Trust all and continue`, `3. Continue without trusting (hooks won't
+  run)`, and `enter confirm · esc skip`. Alternate screen or `--no-alt-screen` drew
+  the same rows.
+
+Without this grammar the unknown option and footers left both gates' option tails
+invalid, so the responder held each gate and never answered it. The two footers are
+bound to their gates (`TrustPromptSpec.footer`): each ends a dialog only under the
+header, explanation, and options of the gate that draws it, and never counts as one of
+the generic native footers that let an off-allowlist gate hold input. Under any other
+dialog, or in conversation text, they make no frame a trust gate. The sanitized
+captures, with the bypass and without, are `tests/fixtures/codex-0.164.0/trust/`.
+C-CODEX-15.
+
 ### Where the clearance grammar lives
 
 "This frame is the CLI's own idle composer, so the gate cleared" is a per-CLI layout
@@ -410,7 +741,9 @@ replacement prompts or future Claude renderers.
 Claude 2.1.278 can paint the complete folder-trust dialog before accepting keyboard
 navigation. In the real human-trust test, immediate Down/Enter writes left the
 selection on "No, exit". Waiting for the selected "Yes, I trust this folder" repaint
-before Enter cleared the dialog. The test records physical PTY writes and confirms
+before Enter cleared the dialog. The 2.1.310 investigation below found the cause, an
+input guard that remounts the dialog, and showed that waiting for the repaint is not
+enough on a loaded machine. The test records physical PTY writes and confirms
 that queued caller input follows native cursor clearance; it does not require a
 model response or available turn quota.
 
@@ -475,11 +808,12 @@ high-trust probe, a manual repeat at eight seconds cleared that same gate; the
 first write had already produced premature startup activity at roughly one second.
 Numbered automation therefore retries every 250 ms for at most five seconds,
 revalidates the same header and exact option identity before each write, and
-reports answered only after the gate clears. A native directory-to-hook transition
+reports answered only after the gate clears. Only the first write carries the
+number; see "Codex numbered trust retries" below for what a retry may send. A native directory-to-hook transition
 confirms directory clearance without sending an old answer to the hook gate.
 An observed clear-and-reappear generation cancels the old attempt.
 
-Cursor navigation rereads between individual arrows and Enter. Both navigation
+Cursor answers reread the frame before every selection and confirmation write. Both navigation
 styles now belong to one session-owned coordinator: each observed dialog
 generation owns its reservation, deadline, exact affirmative, and completion.
 An old cancelled attempt cannot release or settle a reappeared gate. The five-
@@ -503,6 +837,68 @@ PTY exit cancel pending automation and timers before disposal. Only a rejected
 PTY write belonging to a still-live matching attempt emits
 `startup_prompt_write_failed`; cancellation and late settlement stay quiet.
 
+**The five seconds count on-screen time only (Claude 2.1.310, 2026-10-25).** After
+an accepted folder-trust answer, Claude erases the dialog at once but takes
+seconds to paint its composer. In 30 fresh-folder `autotrust` launches, 10 at a
+time (load average 30–70), the dialog was erased 0.17–0.98 s after it first
+painted. The screen then stayed blank, then showed only the welcome banner
+(logo, version, model, path, one rule). The composer painted 4.0–8.9 s after
+the dialog first appeared. That deadline used to run from the first candidate to
+verified composer clearance, so it timed Claude's boot rather than the gate.
+Every launch whose composer came after 5 s went `blocked` with
+`claude-workspace_trust-prompt` attention at +5.0 s, then `ready` when the
+composer painted: 17 of the 27 launches that reached `ready`. At each of those
+blocks the rendered frame held no trust dialog. Another 100 launches the same
+day show the same split: 51 of 94 `ready` launches blocked; the dialog was
+erased 0.05–1.06 s after first paint; erase to composer took 0.72–8.23 s, median
+4.6 s. Headless `elwood run` treats that rule id as a human prompt and kills the
+session: 5 of 7 runs, 14 at once in fresh `$TMPDIR` folders, failed with
+`blocked_prompt`, against none with this change.
+
+The budget therefore elapses only on frames that show the gate: it is five
+seconds of cumulative visible time. A frame without it pauses the budget, and
+the same gate's return resumes the remainder rather than a fresh five seconds,
+so a gate that flickers still exhausts one budget. Only a gate that stays absent
+from its departure through verified clearance is guaranteed never to block. The
+input hold does not change: it lasts until verified composer or successor
+clearance. No separate post-answer
+bound replaces the old one. Boot time grows with load, so any fixed bound only
+moves the false attention later. A CLI that never paints after an answered gate
+leaves the session held, as before, but no longer reported as a trust prompt.
+Interleaved under the same load, 16 at once, the old rule blocked 10 of 16
+launches and this one 0 of 16, with 10 boots over 5 s in each arm. Sixteen
+launches matter: eight on a quiet machine all booted in under 4 s and never
+reached the condition. The sanitized PTY bytes of the slowest launch are in
+`tests/fixtures/claude-2.1.310/trust-slow-boot/`;
+`tests/claude/session-trust-slow-boot.test.ts` replays them at their recorded
+times. `tests/e2e/trust-slow-boot-claude.e2e.ts` launches 16 fresh folders at
+once against the real CLI and logs how many boots exceeded 5 s. C-ATTN-03,
+C-TRUST-01.
+
+**An answer is reported when the composer verifies it, not when the dialog
+leaves (Claude 2.1.310, 2026-10-25).** The blank and banner-only frames between
+the erased folder-trust dialog and the composer show neither the gate nor a
+composer. The attempt read them as its choice vanishing and cancelled itself
+quietly, which is right for a choice lost before its Enter. By then, though, the
+confirming write had fulfilled, so the cancellation discarded a real answer.
+None of the 30 fresh-folder `autotrust` launches above emitted `startup_prompt`,
+although the 27 that reached `ready` had answered their gate. A confirmed
+attempt now waits through dialog-free frames and writes nothing; it re-reads the
+screen only when a new frame renders, so the wait holds no timer. Verified
+composer or successor clearance reports it once. If the same gate returns, the
+attempt answers again within the remaining on-screen budget. Expiry, a changed
+gate, a complete off-allowlist gate, or closing cancels it without a report. With this change, all 21 launches of the two Claude trust e2e
+files (5 at once, then 16 at once with every composer more than 7.5 s after the
+prompt) reported exactly one `startup_prompt`, `sent home+down+enter`. Swapping
+in the previous trust code failed both files: no launch reported its answer.
+Codex 0.164 shows its directory-trust prompt in a fresh git folder, and its
+answers were lost the same way: in four rounds of 4 such launches at once, the
+previous code reported 0 of 16 answers and this change 16 of 16, each `sent 1`.
+`tests/claude/session-trust-slow-boot.test.ts` replays the recorded launch and
+requires exactly one report, and both Claude trust e2e files require one
+`workspace_trust` `startup_prompt` per launch that names a write the launch made. C-CLAUDE-10,
+C-TRUST-01.
+
 Both CLIs reword gates often, so an off-allowlist gate behind a recognized header
 prefix fails closed: a header-shaped region (`headerStart` in
 `src/core/trust/dialog.ts`) with real header text, selectable options, only
@@ -523,6 +919,128 @@ A no-model Codex resize probe at 100×12, 100×8 and 100×6 confirms that the we
 box can scroll away while its composer and model/reasoning/path footer remain.
 Those native rows also prove clearance; welcome presence is not required.
 
+### Codex numbered trust retries (0.164, 2026-10-25)
+
+Under `autotrust`, Codex 0.164 sometimes received "1" as a user message right
+after its directory-trust gate. Elwood wrote `1\r` when the `Folder access` gate
+painted, then wrote `1\r` again 250 ms later because the frame still showed the
+gate. Under load Codex had taken the first answer but painted its composer after
+the retry, so the second `1\r` submitted "1" as a turn. In one capture the writes
+landed at 21.26 s and 21.52 s, and the transcript then showed `› 1` with the turn
+running at 24.7 s.
+
+Codex also discards keys written as the gate paints. In 8 fresh git folders
+launched at once (load average about 140), with `autotrust` off and a probe
+typing `1\r` 8–33 ms after the gate's first frame, 7 of the 8 answers were
+dropped. No output followed for 3 s. A bare `\r` then confirmed the
+highlighted `› 1. Trust and continue` 24–156 ms later in all 7. The eighth
+answer (written 13 ms after the gate's first frame) was taken. Once each
+composer painted, a bare `\r` on the empty composer submitted nothing in 8 of
+8: no hook fired, no `Working` row, and the status stayed `ready`. Typing `1`
+alone selects option 1 without confirming it (the gate stayed for 40 s). So
+neither a time limit nor new output can tell a dropped answer from one Codex
+is still processing, and a dropped answer produces no output to wait for.
+
+Elwood therefore types the number in its first write to a gate, and never
+again on a stale frame alone. While the
+rendered caret is on the affirmative, a Codex retry is Enter alone, every
+250 ms within the gate's five on-screen seconds. On the gate it confirms the
+highlighted affirmative; on the empty composer it does nothing. Claude never
+gets a bare Enter (its list remounts with the caret on the decline; see the
+next section), and Codex's hook gate opens with its caret on `Review hooks`.
+Those numbered gates are answered again only after a frame rendered from
+output that arrived after the last write still shows them. Once Elwood has
+started writing the number to a gate, every later attempt at it retries this
+way, even when that write or a retry was rejected, since a rejected write may
+still have reached the CLI. Only another complete dialog replacing the gate
+makes its return a fresh gate that gets the number.
+`tests/codex/session-trust-slow-answer.test.ts` covers both cases.
+
+Measured with 8 fresh git folders launched at once per round and two rounds per
+arm, at load average 20–60 (leaked shell processes were also slowing the
+machine): on the previous code, 9 of 16 launches typed `1` into the composer (2
+to 11 `1\r` writes each), and only 5 of 16 reported their answer. With this
+change, 0 of 16 did: each typed the number once, then 1 to 15 bare Enters, and
+all 16 reported `sent 1`. `tests/e2e/trust-retry-codex.e2e.ts` makes the lag
+certain by holding Codex's output from Elwood for 2 s after the answer while
+Codex runs normally. On the previous code it failed both runs: seven more `1\r`
+writes reached the composer, "11" was submitted, and the model answered "What
+would you like me to do with 11?". With this change it passed 3 of 3. Freezing
+Codex itself (SIGSTOP for 2 s right after the answer) does not work as a test:
+Codex then exits with `timed out discarding buffered terminal input`, whatever
+Elwood types. Codex 0.164 discards buffered input at screen changes like this
+one, and a stalled discard is fatal.
+
+### Claude trust selection reset (2.1.310, 2026-10-25)
+
+Under `autotrust`, 7 of 60 fresh-folder launches of Claude Code 2.1.310 exited
+with code 1 at the folder-trust gate on a loaded machine (load average 60–160 on
+16 cores, three to six launches at once). Every failure had the same shape. Elwood
+wrote `\x1b[B` (twice in two runs, the second a 250 ms retry), Claude painted
+`❯ Yes, I trust this folder`, and Elwood wrote a bare `\r`. Claude then repainted
+`❯ No, exit` without any key from Elwood and ran its exit sequence
+(`\x1b[?1006l…\x1b[?25h`). In two runs the repaint and the exit sequence arrived in
+one output chunk.
+
+The 2.1.310 binary explains it. `TrustDialog` renders its confirm list with
+`cancelFirst`, `focus: "cancel"` and a React key of `"held"` or `"settled"`. The key
+flips to `"settled"` 150 ms after the dialog mounts. An Enter within 150 ms of mount,
+or of an earlier refused Enter, is refused, and the refusal flips the key back to
+`"held"` for another 150 ms. Each key change remounts the list with the cursor on
+"No, exit". On a busy machine the settle timer is already overdue when Claude next
+reads stdin, so it runs first. The Enter that Elwood decided from the `❯ Yes` frame
+is then processed on the remounted list and confirms "No, exit". A probe that sent
+only Down at first paint saw `❯ Yes` and then `❯ No, exit` 90 ms later, with no
+Enter. A refused Enter only resets the cursor: that is the "first Enter is lost"
+pattern in successful runs (Down, Enter, reset, Down, Enter). Separately, Down on
+the last row wraps to the first. In one run a stalled first arrow and its 250 ms
+retry both landed, painting `❯ Yes` and then `❯ No, exit`; an Enter decided between
+them would also confirm "No, exit". Every installed binary from 2.1.268 to 2.1.310
+carries the same remount key on this dialog (the 150 ms window was read from 2.1.305
+and 2.1.310), and the MCP-server dialog uses it too.
+
+Claude's list binds `home` to `select:first` and `end` to `select:last` in every
+installed binary from 2.1.268 to 2.1.310. A live 2.1.310 probe confirmed that Home
+(`\x1b[H`) and End (`\x1b[F`, `\x1b[4~`, `\x1bOF`) move the trust cursor absolutely
+and repeat harmlessly. Written as one chunk, `\x1b[H\x1b[B\r` confirmed "Yes" in
+every probe and every fixed launch, including launches where the remount ran just
+before the chunk was read.
+The list's key handlers read focus through a synchronous getter, so one chunk's keys
+see each other's effect. Inside the 150 ms windows the chunk is refused, which is
+harmless, and the next retry succeeds. Elwood therefore writes Home plus one Down
+per row above the affirmative while the rendered cursor is elsewhere. Once the
+cursor is on the affirmative, it writes that selection and Enter as one write.
+Relative arrows and bare Enter are never sent. With that rule, interleaved with the
+failing runs under the same load, 0 of 51 launches exited. In 7 of them Claude
+repainted `❯ No, exit` after the combined write and still accepted it; with a bare
+Enter that interleaving exits. `tests/unit/trust-claude-selection-reset.test.ts`
+replays the real 100×30 frames (`tests/fixtures/claude-2.1.310/folder-trust-*.txt`)
+against a model of this dialog. `tests/e2e/trust-prompt-claude-concurrent.e2e.ts`
+launches five fresh folders at once and checks every trust write at the PTY
+boundary.
+
+### Codex takes a trust answer before Elwood's frame shows it (0.164, 2026-10-25)
+
+Elwood decides each startup retry from the frame it has rendered, and under load that
+frame trails Codex. Codex 0.164 can take the trust answer and draw its composer while
+Elwood's frame still shows the folder-access gate. A retry decided from that stale
+frame lands in the composer. Keys a caller types in that window also reach the
+composer, so a `1\r` retry written after them would add a digit to the caller's draft
+and submit it as a turn.
+
+`tests/e2e/trust-caller-input-codex.e2e.ts` makes the window certain. It holds Codex's
+output from Elwood for 4 s after the first `1\r`, and types `hello` as soon as Codex's
+raw output draws its configured composer (the footer naming the session's model). On
+`main` at 6e396099, at load average 34, Elwood kept retrying the stale gate every
+250 ms: 14 more `1\r` writes followed `hello`. Raw caller input now hands the startup
+prompt on screen to the caller before its keys are written (C-TRUST-01). In two runs
+with that handoff, nothing followed `hello`.
+
+The Codex update skip has the same ordering. A `2` decided from a stale update prompt
+would reach whatever Codex drew next; on the trust gate, `2` is Quit. Caller input
+ends the skip, and the update stays the caller's until a native composer clears it,
+because Elwood's frame can lose and regain a stale prompt in between (C-CODEX-12).
+
 ### Native Codex startup warnings
 
 Codex 0.154.0 normally collapses MCP failures to
@@ -533,6 +1051,22 @@ does not send Ctrl+T automatically. Captures and the local failing-server/401
 real-CLI test verify the detailed rows. The current welcome chrome and native
 warning prefixes distinguish these banners from conversational quotations.
 
+**Codex 0.164.0 shows only a badge (2026-10-25).** In C-E2E-09's native run (an MCP
+server answering 401, `startup_timeout_sec = 2`), the welcome is no longer boxed, and
+the only startup trace is `⚠ 1 warning · f2 to view` at the end of the composer's
+model footer, which the composer clearance already strips. Ctrl+T opened the
+`/ T R A N S C R I P T /` overlay. It holds both canonical rows, the `elwood_probe`
+not-logged-in row with its `codex mcp login elwood_probe` command and
+`⚠ MCP startup incomplete (failed: elwood_probe)`, under an unboxed
+`>_ OpenAI Codex (v0.164.0)` and above the overlay's own key hints. That overlay is
+Codex's transcript view, where the conversation also renders, so it is not a startup
+region; the parser finds no welcome box there and returns nothing. Elwood sends neither F2 nor Ctrl+T, so on 0.164 a
+session emits no MCP startup warning: the count names no server and no recovery
+command (PRD §5.7, C-CODEX-09). The captures are
+`tests/fixtures/codex-0.164.0/boot/warning-badge.txt` and
+`warning-transcript-overlay.txt`; C-E2E-09 asserts the badge, that its frame reads as
+the composer, and that no warning parses from it.
+
 Native 0.154.0 startup renders no `•`/`●` row at any point: recorded frame by frame
 (2026-09-17) through the directory gate, hooks gate, welcome, and composer with
 both an MCP endpoint that fails at once and one that accepts the connection and
@@ -559,13 +1093,39 @@ The acceptance is persisted in Claude's global config as
 `bypassPermissionsModeAccepted` (the binary describes it as "Whether the user has
 accepted the bypass permissions mode dialog"), and `--bg` refuses bypass mode
 until it has been accepted once interactively, so the dialog is at most
-once-per-machine. **Empirically, on 2.1.268 (Claude Max account, macOS) the
-dialog did NOT render at all** — neither through Elwood's `--permission-mode
-bypassPermissions` launch nor with a raw `--dangerously-skip-permissions`
-launch — and no `bypassPermissionsModeAccepted` key existed anywhere under
-`~/.claude*`; the session went straight to the composer with the persistent
-`⏵⏵ bypass permissions on (shift+tab to cycle)` footer. Whether it appears is
-therefore version/account-gated, and Elwood must be correct in BOTH states:
+once-per-machine. On 2.1.268 (Claude Max account, macOS) the dialog did not render
+at all, through Elwood's `--permission-mode bypassPermissions` launch or a raw
+`--dangerously-skip-permissions` one, and no `bypassPermissionsModeAccepted` key
+existed anywhere under `~/.claude*`. The likely reason is a user setting, not the
+version or account: the developer's `~/.claude/settings.json` sets
+`"skipDangerousModePermissionPrompt": true`. On 2.1.310, in a config that has never
+accepted the dialog, that setting alone decides whether it renders: in an empty
+`CLAUDE_CONFIG_DIR` (no settings, never accepted) the dialog renders, and adding the
+setting there sends the session straight to the composer. The 2.1.310 copy
+is longer and opens with the cursor on the decline
+(`tests/fixtures/claude-2.1.310/bypass-permissions-{100,200}.txt`):
+
+```
+WARNING: Claude Code running in Bypass Permissions mode
+
+In Bypass Permissions mode, Claude Code will not ask for your approval before running potentially dangerous commands.
+This mode should only be used in a sandboxed container/VM that has restricted internet access and can easily be restored if damaged.
+
+By proceeding, you accept all responsibility for actions taken while running in Bypass Permissions mode.
+
+https://code.claude.com/docs/en/security
+
+❯ No, exit
+  Yes, I accept
+
+Enter to confirm · Esc to cancel
+```
+
+Until the native-copy pattern accepted the sandbox sentence and the link, Elwood
+held this dialog as unrecognized prose and the session stayed `blocked` under
+`autotrust`. The suite never saw it because the developer's setting hid it, so
+whether it appears depends on the user's settings and Elwood must be correct in
+BOTH states:
 
 - The dialog is an allowlisted trust prompt (`bypass_permissions`), answered
   under `autotrust` by the same header-anchored, numbered-or-cursor machinery as
@@ -598,6 +1158,40 @@ prompt; `--no-trust` and generic permission dialogs remain human blocks. The sta
 deliver this attention after the responder has already continued, so treating
 every attention event as fatal produces a false `blocked_prompt`.
 
+### Claude keeps the prompt's caret after a declined permission dialog (2.1.310, 2026-10-26)
+
+A real Claude 2.1.310 session in `default` mode (189x48, Opus 5.5, a private
+`CLAUDE_CONFIG_DIR` with no user settings) asked to create a file rendered the
+`Do you want to proceed?` dialog with its cursor hidden. Escape declined it. The next
+frame showed `⎿  Interrupted · What should Claude do instead?`, the idle composer
+fenced by rules, the `⏸ manual mode on · ? for shortcuts` footer, a visible cursor at
+column 2, and the idle title `✳`. The transcript above it still held the submitted
+prompt, echoed as `❯ Create a file named …`. Claude echoes every submitted prompt that
+way, so the whole-frame clearance, which rejects any caret row that is not an empty
+composer, rejected the frame, and the session stayed `blocked` while Claude sat idle:
+15 s in the capture, and the whole wait of a C-ATTN-01 run in the same private config.
+Attention clearance now also accepts the last composer with its rules and native
+footer (`claudeLastComposerClearance`), the path the model picker already used for
+`❯ /model` (`tests/fixtures/claude-2.1.310/permission-declined/`). The real-CLI C-ATTN-01 runs
+Claude with the developer's own config dir, and had not caught this on the developer's
+machine: their own `PermissionRequest` hook allowed the command, so the dialog never
+rendered there. This capture is a manual reproduction in a private config dir with no
+user hooks. C-ATTN-02.
+
+A resumed session repaints those carets too. In the same private config, a `default`-mode
+session ran one turn and was stopped, then resumed with `highTrust`. Bypass mode had
+never been accepted there, so the resume opened on the bypass-permissions dialog, and
+autotrust answered it. Claude then painted the resumed transcript, with
+`❯ Reply with exactly: hello. …`, above the idle bypass-mode composer, its footer, and a
+visible cursor at column 2. Startup trust clearance used the same whole-frame check,
+so the answer never settled. The session sat at `running` for the 60 s observed and
+never reached `ready`. Startup trust clearance now uses the same predicate as attention
+clearance (`tests/fixtures/claude-2.1.310/resume-bypass/`). Rerun with that change, the same
+resume answered the dialog, recorded a `bypass_permissions` startup prompt, and reached
+`ready` 4.6 s after launch. A folder-trust gate on
+resume goes through the same clearance, but that case was not captured. C-TRUST-01,
+C-CLAUDE-21.
+
 ## Codex in-TUI update prompt (and the restart loop)
 
 Independent of the `autoupdate` preflight (`codex update` run before spawn), the
@@ -703,6 +1297,241 @@ other errors, pre-exit errors, and persistent `EPERM` still fail. Controlled
 shutdown also leaves the reap to its owning termination path instead of emitting
 a competing best-effort warning. Verified against Codex 0.153.3 on macOS.
 
+## Hook and MCP process groups (2026-10-25)
+
+Claude Code 2.1.310 and Codex 0.164.0 start every hook command with `setsid()`.
+Measured on macOS with `ps -o pid,ppid,pgid,command` and `os.getsid()` while a
+slow hook was in flight under a real Elwood session:
+
+- Claude runs a hook as a direct child of the CLI (`ppid` = the PTY leader) whose
+  `pgid` and `sid` both equal its own pid. A compound command runs as
+  `/bin/sh -c '<command>'`; a plain one such as Elwood's
+  `'<node>' '<bridge>.mjs'` is executed directly. An Electron host's
+  `ELECTRON_RUN_AS_NODE=1 …` command needs the shell, consistent with the
+  reported orphan `/bin/sh -c node hook-bridge.mjs`.
+- Codex runs a hook as `/bin/zsh -c '<command>'` (the user's shell), also with its
+  own `pgid` and `sid`. Codex started an MCP server (`node ./scripts/start-mcp.mjs`,
+  from a plugin it installed in the sandboxed `CODEX_HOME`) in its own process
+  group but inside the leader's session.
+- The children the CLI starts without detaching, such as Claude's IDE probe
+  (`ps aux | grep …`), stay in the leader's group.
+
+So the leader-group SIGKILL (`kill(-leader)`) cannot reach a hook. Once the
+leader dies the hook is reparented to PID 1 and nothing ties it to the session;
+only the parent-pid chain links a hook to its leader, and only while the leader
+lives. With the group reap alone, `teardown()` during a `SessionStart` project hook
+running `sleep 45` resolved in 25 ms and left that `/bin/sh` and its `sleep` alive
+under PID 1. `stop()` while a `SessionEnd` hook ran `sleep 46` timed out after
+5 s; Claude waits for `SessionEnd` hooks on SIGTERM, so Elwood escalated to SIGKILL
+and left the hook running. On Codex, `teardown()` during a `UserPromptSubmit`
+config hook left the `zsh`/`sleep` group alive, and the MCP server group outlived
+the CLI briefly. Elwood's own bridge processes died only because teardown then
+closes the bridge socket; the reap itself never reached them.
+
+When Claude exits on SIGTERM within the graceful window it kills its in-flight
+hooks itself: a `stop()` during the same `sleep 45` hook exited in about 1 s with
+no survivors. On macOS, `killpg` on a group whose members are all unreaped zombies
+returns `EPERM`, not `ESRCH`. `src/runtime/shutdown/process-table.ts` reads the
+table and finds these groups by walking parent pids from the leader.
+
+Elwood therefore walks the tree only before a SIGKILL it sends to a live leader. It
+SIGSTOPs the leader's group and lists
+`/bin/ps -A -o pid=,ppid=,pgid=,stat=,lstart=,ucomm=,pid=` (the start time tells a reused
+pid from the process that had it; the short name and the pid again are for Codex's
+daemon, below). A
+group id from `ps` is only a snapshot, `kill()` returning means the SIGSTOP was sent,
+not delivered, and `ps` reads each process's state at its own moment (on macOS it
+takes the set of pids first and each row's state afterwards). So Elwood relies only
+on a process that read stopped (`stat` starting with `T`), inside a group it stopped,
+in two consecutive listings. A group that holds a live descendant is stopped once
+such a process is a parent of one of its members: that parent cannot reap the
+member, so the group keeps its id until the signal. The walk succeeds only on a
+listing that shows the leader live, leaves no live group unreached, and holds every
+live process in every stopped group that way, the leader's included, so none of them
+can have started a process the listing missed; a leader exit observed first fails it,
+because the leader's detached children are then out of reach. Then the stopped groups
+are SIGKILLed deepest first, except one that holds Codex's daemon, which is resumed
+(below) (`src/runtime/shutdown/detached-sweep/`). That is two listings with no hook in
+flight, and two more per level of nesting. A process whose own parent exited before
+the walk is already under PID 1 and out of reach. macOS refuses a stop or a kill of
+a group whose members are all unreaped zombies with `EPERM`, so either counts as a
+failure only if a later listing still shows a live member of that group.
+
+`killpg` is not atomic against `fork` (measured 2026-10-25, Claude 2.1.310, macOS
+Darwin 25.5): a child forked while the group's SIGSTOP goes out can miss it and keep
+running. The PTY leader is the user's interactive login shell (§4.2), and in one
+Claude `teardown()` out of nine, with no hook in flight, `claude` had already exited
+and the shell was running a `$(… | tr …)` pipeline from the user's shell
+configuration. One subshell of it read `R` on every listing for the whole
+three-second deadline while the rest of the group read `T`, so the leader's group was
+never held and `teardown()` rejected. A zsh group forking `$(echo a | tr a b)` in a
+loop, SIGSTOPped once, left one member running in 1 of 150 stops, and a second
+SIGSTOP stopped it every time. So any listing that shows a live process in a stopped
+group not stopped sends that group SIGSTOP again: the leader's only while its exit
+has not been observed, a descendant group because its held parent keeps the id. A
+listing cannot tell a stop still in flight from a missed one, and a second SIGSTOP
+to a stopped process does nothing, so the walk does not try to. With the re-stop, 40
+of 40 real no-hook teardowns completed, 5 of them sending the leader's group a
+second SIGSTOP; without it, 1 of 9 had rejected.
+
+The walk's cost, measured 2026-10-25 on Claude 2.1.310 on a shared machine: one `ps`
+listing of about 1,800 rows took 110–240 ms at load 33–35. At load 19–26, ten
+`teardown()`s with no hook in flight took 81–291 ms (median 227, two listings), and
+ten with a `SessionStart` hook in flight 175–567 ms (median 373, four), against 2–3
+ms and 7–18 ms with the walk disabled, where the in-flight hook survived every time. `tests/e2e/teardown-reap.e2e.ts` drives the
+real CLIs: Claude `teardown()` with a hook in its own group, a `stop()` whose
+`SessionEnd` hook outlasts the graceful window, and Codex `teardown()` with a hook.
+With the walk disabled all three fail with the hook still running.
+
+On a loaded host the walk outgrew its first three-second deadline (measured
+2026-10-26, macOS Darwin 25.5, about 3,700 processes on the host). A `kill()` of a
+setsid hook with a setsid child of its own takes six reads. That is two to hold the
+leader's group, and two more for each level of nesting. At a 1-minute load of 70 to
+92, those reads took 78–644 ms each, and the walk took 1.1–2.6 s. Under the
+repository's own parallel test run on that host, reads passed half a second, and so
+six of them passed three seconds. `kill()` then rejected with `termination_failed`,
+though each read was making progress. The deadline is now ten seconds.
+`tests/unit/sweep-deadline-real.test.ts` slows each real read by 600 ms and checks
+that `kill()` still reaps such a tree.
+
+Codex also starts a shell of its own, not a hook, that the walk has to reach
+(measured 2026-10-25, Codex 0.164, macOS Darwin 25.5). A few seconds after launch
+(2.1–2.6 s after `startCodex` was called, in these runs) it snapshots the user's
+shell environment with `/bin/zsh -lc '<script>'`. The script sources
+`$ZDOTDIR/.zshrc`, else `$HOME/.zshrc`, then prints the environment. The shell is a
+session leader of its own (`stat` `Ss`, `pgid` equal to its pid) whose parent is the
+`codex` leader. With a normal profile it lived about 0.8 s. A `.zshrc` that sleeps
+only when non-interactive (`[[ -o interactive ]] || sleep 120`) holds it open without
+slowing the PTY's own interactive login shell, and with that profile:
+
+- `teardown()` with the group reap alone left the `zsh -lc` and its `sleep` running
+  under PID 1. With the walk, `teardown()` and `kill()` reaped both.
+- `stop()`'s SIGTERM: Codex exited in about 190 ms. The leader exited within the
+  graceful window, so there was no walk, and both the `zsh -lc` (now under PID 1)
+  and its `sleep` survived.
+- A human at the terminal, `/quit` then Enter, or Ctrl-C twice: Codex exited about
+  6 s after the keys. The `zsh -lc` was gone, but the profile's `sleep` survived
+  under PID 1.
+
+Claude 2.1.310 under the same profile started no shell that sources `.zshrc`
+non-interactively, and nothing survived. So the premise behind the graceful-stop
+exception, that the CLI's own SIGTERM shutdown ends its detached descendants, holds
+for Claude's hooks but not for this Codex shell: a `stop()` during the snapshot
+leaves it running. `tests/e2e/codex-snapshot-reap.e2e.ts` holds a snapshot open
+this way and checks that `teardown()` reaps it.
+
+## Codex 0.164 starts an app-server daemon per `CODEX_HOME` (2026-10-25)
+
+Codex 0.158.0 and later list the feature `daemon_auto_start` as stable and on (0.156.1
+lists it as experimental and off; 0.155.1 does not have it). With it, the Codex 0.164.0
+TUI can start a managed app-server daemon for its `CODEX_HOME`. Measured on macOS
+(Darwin 25.5) with fresh homes: 11 of 14 launches without the hook-trust bypass started
+one, the earliest beginning its install 1 s after launch, and none of 5 launches with
+the bypass did, one of them an Elwood session watched for 17 s. What decides it was not
+determined. The e2e suite's removed homes had left 29 of these daemons running by that
+evening.
+
+- It installs a copy of the CLI, about 260 MB, at
+  `$CODEX_HOME/packages/app-server-daemon/releases/<version>/bin/codex`. One such home
+  measured 453 MB.
+- It runs `codex app-server --listen unix:// --analytics-default-enabled --managed-daemon`
+  and `codex app-server daemon pid-update-loop`. Each is a session leader of its own and
+  a child of the TUI, reparented to PID 1 when the TUI exits. The control socket is
+  `$CODEX_HOME/app-server-control/app-server-control.sock`, pid files are under
+  `$CODEX_HOME/app-server-daemon/`, and a socket directory and lock are under
+  `/tmp/codex-daemon-<uid>/`. Plugin MCP servers (`node ./scripts/start-mcp.mjs`) run as
+  its children.
+- The TUI then reads through it as client `codex-tui`. The daemon's rows in
+  `logs_2.sqlite` show `account/read`, `config/read` (the project trust read),
+  `hooks/list`, and `model/list`.
+- It outlives the TUI. Those 29 daemons had started 14 minutes to 1 h 49 min earlier,
+  their homes removed seconds after, and were all still running, each holding its
+  deleted binary. They refreshed `models_cache.json` and recreated `logs_2.sqlite`,
+  `.sqlite-maintenance.lock`, and the plugin cache in the removed home. A removal that
+  raced those writes failed with `ENOTEMPTY` (C-E2E-09, 1 run of 3).
+- `codex app-server daemon stop`, run with that `CODEX_HOME`, stopped the daemon and its
+  MCP servers but left the updater loop running. SIGTERM ended both within 2 s, and the
+  daemon stopped its MCP servers and removed its `/tmp/codex-daemon-<uid>/` entries.
+  `codex app-server daemon start` started both on every run, in about 2.5 s.
+
+Elwood's sessions use the user's own `CODEX_HOME` and always bypass hook trust, so a
+daemon there is the one the user's own Codex shares, as for a human at the terminal. The
+e2e suite stops whatever still runs from a sandbox or from its default home before
+removing it (`tests/e2e/scratch-processes.ts`). That is every process whose command line
+names a path inside the home, plus its descendants: SIGTERM first, then SIGKILL 3 s
+later. A sandbox where something will not stop is kept.
+`tests/e2e/scratch-processes.e2e.ts` starts a daemon with `daemon start` and checks that
+removing the sandbox, and exiting the run, stop it.
+
+## Elwood's teardown never kills that daemon (2026-10-26)
+
+While the TUI that started them runs, the daemon and its updater loop are setsid
+children of it, the shape of a hook in flight. So when a session's own TUI had started
+them, the detached walk that `kill()`, `teardown()`, and a `stop()` escalation run killed
+the daemon, its updater loop, and everything the daemon had started, though the daemon
+serves every Codex on the home, the user's own included. The walk now never descends into
+one (PRD §5.3, C-LIFE-10): a process whose `ucomm` (short name) is `codex`, that leads its
+own group, whose parent is named `codex` or is PID 1, and whose `comm` has
+`/packages/app-server-daemon/` in it. On macOS `comm` is `argv[0]`, which Codex sets to
+the full path; it reads that way even after the home is removed.
+
+`comm` is read, one `ps -o comm= -p <pid>` per process and at most four at once, only for
+the processes that pass the other tests and that the walk can reach: the session's TUI and
+its descendants. None starts past the table read's deadline; the read then fails as a timed
+out one does. Every extra read costs a walk whose deadline, three seconds when these were
+measured, must hold on a loaded host:
+
+- `comm` in every table read doubled its cost (94 to 200 ms at a load of about 220): 4 of
+  9 real-process reap tests failed with `ETIMEDOUT`, none on `origin/main`.
+- Given several pids, macOS `ps` reads every process on the host (230 to 370 ms at a
+  load of about 25): with one `ps -p` for all candidates, a real Codex `teardown()`
+  failed in 5 of 7 runs, none of 2 on `origin/main`.
+- One `ps` per candidate anywhere on the host took 4 to 9 ms from a shell, but 120 to
+  870 ms when spawned by the process tearing the session down. The user's own daemon was
+  always a candidate, so every read paid that again: a real Codex `teardown()` failed in
+  2 of 5 runs, none of 5 on `origin/main`.
+
+A walk remembers each daemon it found, by pid, parent, and group, so when the session's
+TUI started one, the walk's first read pays its path reads, and no later read does unless
+its parent changed. A candidate no read has confirmed, such as the TUI's fork before its
+`exec`, is read again on every read until one does or it is gone. A walk with no
+candidate under its TUI runs the same single `ps` per read as before. In 3
+real Codex `teardown()`s, alternated with 3 on `origin/main`, it ran no path read. One run
+on each side failed at the deadline, when the host's 3,700 processes made a single table
+read take 1.6 to 2.1 s; the other reads took 350 to 540 ms.
+
+No real-Codex e2e proves this: in 8 runs of Codex 0.164.0 under Elwood, from fresh
+homes, with and without the hook-trust bypass and the update check, with holds of up to
+40 s, none started the daemon. `tests/unit/reap-detached-real.test.ts` builds the
+measured shape from real processes instead, with its install in place and removed.
+
+The TUI forks the daemon as a `codex` group leader of its own and then `exec`s it, so a
+path read can come between the two, and the walk can then stop the group after the
+`exec`. A stopped process cannot `exec`, so the kill pass goes by the latest read: a group
+it shows holding the daemon, or a process not stopped that could still become it, gets
+SIGCONT, not SIGKILL. A leader killed by something else while the walk holds it leaves
+that stopped daemon under PID 1, out of the leader's reach, so each group the walk stopped
+is a root of its own for the path reads. `tests/unit/shared-daemon-real.test.ts`
+reproduces both with a real process: Node cannot `exec`, but setting `process.title`
+changes what macOS `ps` reads as `comm` (`ucomm` stays the executable's name).
+
+A descendant can set its `comm` to the daemon's path (Node does by setting
+`process.title`), and a binary named `codex` that leads its own group is then spared as
+the daemon would be. That gives it nothing it lacks: the walk follows parent pids from the
+leader, so a descendant whose parent exits first is out of its reach. Measured on
+`origin/main` (2026-10-26): a setsid hook that backgrounds `/bin/sleep 300` and exits
+leaves the sleep under PID 1 before `kill()`, which resolves with the sleep still running.
+
+## `ps` prints a process's short name raw (2026-10-26)
+
+To recognize Codex's daemon (above), each table read also lists every process's short
+name (`ucomm`), and `ps` prints it raw. A process whose name is `a`, a newline, and
+`1 5000 1 S    ` reads as two rows, the second a forged process 1 whose parent is 5000
+(measured on macOS 26). `comm` and `ps -c` escape it as `\012`, but `comm` in every table
+read doubled its cost (94 to 200 ms at a load of about 220). So each row ends with its pid
+again (`-o pid=,ppid=,pgid=,stat=,lstart=,ucomm=,pid=`), and a read with any line that
+is not one whole row, or one pid twice, is unreadable: the walk fails rather than act on it.
+
 ## Claude "Not logged in" is a distinct re-auth banner from "Login expired"
 
 Claude's mid-session re-auth banners are NOT one string. Besides the lapsed/revoked
@@ -747,6 +1576,13 @@ new CLI version or native capture was verified.
   means observed: each write first awaits `terminal.settled()`, because a dialog can
   be received before it is rendered. xterm parses the first write after user input
   synchronously and later ones on a timer, so that window is real and input-dependent.
+- Claude 2.1.310 shows a message submitted during a running turn as queued. It renders
+  as `❯ <message>` above the composer, with `ctrl+x ctrl+s to send now` beneath it, and
+  the composer reads `❯ Press up to edit queued messages`. In a turn told not to use
+  tools it was still queued 10 s later, with the reply still streaming. A check that the
+  message left the composer must read only the last `❯` line, because the queued row
+  also starts with `❯` and holds the message. Observed with `sendGuidance` in a private
+  config dir, 2026-10-26 (C-API-37).
 - **Writing a literal ESC byte in source is fragile** — it can be silently
   stripped by an editor/pipeline (this once neutered an interrupt e2e). Always
   write the escape sequence form (``), never a raw ESC character.
@@ -836,8 +1672,9 @@ Four real-PTY edges were invisible to the unit fixtures:
 - Codex 0.153.3 can paint the numbered menu before its input loop accepts the first
   hotkey. A successful PTY write therefore does not prove the dialog cleared. The
   responder runs one bounded retry operation while a safe numbered option remains
-  on the current rendered frame; once it disappears, no delayed key can reach the
-  composer. Some PTY hosts close their input side before process completion and
+  on the current rendered frame. A frame showing the option does not prove the key
+  was ignored, so a retry can still reach the composer; it is Enter alone, or it
+  waits for new output (see "Codex numbered trust retries"). Some PTY hosts close their input side before process completion and
   then return `EIO` from `setRawMode(false)`; contain only terminal-gone restoration
   errors because that host is already the sole remaining terminal-mode owner.
 - Interactive login-shell probes can give their external command control of the
@@ -893,11 +1730,30 @@ five rows in ~6s; real Codex six rows in ~5s. Two environment facts matter:
 - When Elwood itself runs nested inside a Claude Code session (`CLAUDECODE` and
   `CLAUDE_CODE_*` set), claude >= 2.1.201 skips transcript persistence for the
   nested instance; a headless run then fails `wait_timeout` ("transcript did not
-  catch up after ready") and floods `transcript_read_error (ENOENT)`. The e2e
-  helper strips those variables; do the same for manual smoke runs.
-- Even outside nesting, one `transcript_read_error (ENOENT)` warning appears at
-  Claude startup before the first turn creates the transcript file. It is
-  pre-existing run behavior, not specific to `models`.
+  catch up after ready"). The e2e helper strips those variables; do the same
+  for manual smoke runs.
+- **Claude 2.1.310 creates the transcript file only when the first turn is
+  submitted (2026-10-25).** `SessionStart` already carries `transcript_path`, but
+  the file was still absent 4 s after `ready` in every probe and appeared about
+  1 s after the first prompt. Elwood used to report each 500 ms poll of that
+  missing file as `transcript_read_error (ENOENT)`: 12–13 warnings per session
+  with a 4 s idle, and a flood when nested persistence never creates the file.
+  The Claude cursor now treats ENOENT as "not created yet" until a stat has
+  seen the file. ENOENT after that, and any other read error, still warns.
+  Codex never warned here: its shared cursor's `fileSize` already maps ENOENT
+  to an empty file. C-CLAUDE-24.
+- **That same mapping hid a removed Codex transcript (2026-10-25).** On Codex
+  0.164.0, `SessionStart` arrives only with the first submission, and its
+  `transcript_path` is a realpath (`/private/var/…/sessions/YYYY/MM/DD/rollout-…jsonl`
+  under `CODEX_HOME`); the file exists by the time that turn's `task_complete` is
+  committed. Deleting it afterwards made the next poll read size 0, which the
+  cursor took for a truncation, so nothing warned and the session's later
+  transcript activity was silently gone: no `transcript_read_error` within 10 s
+  on `main`. The Codex scan now reads through the shared cursor's existence
+  policy, as Claude's does: until a stat has seen the file, ENOENT waits silently;
+  after that, every poll, and the final flush, warns with `ENOENT` while the file is
+  missing. A file that reappears is read with the
+  existing truncation rule. C-CODEX-23.
 
 `elwood sessions` reports `live` from the presence of a `.sock` file in the
 session's stable socket home. A connect probe was rejected on purpose: the
@@ -905,6 +1761,72 @@ bridge treats any connection that closes without a frame as a malformed request
 and emits `hookError`/`activity` on the live owner, so presence is the only
 side-effect-free signal. C-CLI-21 through C-CLI-24.
 
+## Probe shell startup under concurrency (2026-10-25)
+
+Preflight probes run through the user's interactive login shell (§4.2), so their wall
+time is the user's profile plus the CLI. On a 16-CPU host already at load 35–90 with a
+typical developer profile (oh-my-zsh with seven plugins, `nvm.sh`, `fnm env`,
+`brew shellenv`), measured with Claude Code 2.1.310:
+
+- `claude --version` without a shell took 0.01–0.12 s at 1, 4, 8 and 16 concurrent
+  runs. There is no `~/.claude.json` lock, autoupdate check or keychain wait on this
+  path. An empty `CLAUDE_CONFIG_DIR` changed nothing, and `zsh -l -i -c true` costs
+  the same as the real probe.
+- The interactive login shell alone took 2.3–7.6 s for one probe, about 2 s each at 4
+  concurrent, about 5 s at 8, 7–19 s at 16 (p50 8–18 s), and 15.5–30.9 s at 32. A
+  trace of one startup put about 2.5 s in `nvm.sh`'s command substitutions and 1.2 s
+  in `compinit`/`compdef`. Fresh or shared working directories made no difference, so
+  this is CPU saturation from fork-heavy startup files, not a shared lock.
+- With an empty private `ZDOTDIR`, the same probe took 0.03–0.23 s at 16.
+
+The original 15 s bound covered both phases. 16 concurrent `elwood run`s therefore
+failed `claude_start_failed` ("`claude --version` failed", `ETIMEDOUT`) at 17.5–18.9 s:
+16 of 16 in one of three fleets at load 68, and 14 of 16 in the original report. The
+probe shell now writes `elwood-probe-command-start` on descriptor 3, a fourth pipe the
+runner opens, just before the command, then closes it so the command does not inherit it.
+Writing it to stderr was the first version; a review pointed out that a profile running
+`exec 2>&1` or `exec 2>/dev/null` would hide it. Real zsh with this host's profile, and
+zsh with either redirect in a private `ZDOTDIR`, delivered the line on descriptor 3. The
+bash check ran `bash --rcfile … -i`, a non-login shell, which keeps descriptor 3 too; macOS's
+bash as an interactive login shell does not (next section).
+The profile gets a 60 s launch bound and the CLI keeps 15 s from that line (C-PERF-05).
+With the stderr version, three 16-run fleets at load 48–74 passed preflight 48 of 48;
+the bounds are the same on descriptor 3. The real-shell e2e
+uses a private `ZDOTDIR` whose `.zshrc` sleeps 4 s with a 2 s command bound; `main`
+fails it with that same `ETIMEDOUT`.
+
+## Probe start line under macOS bash 3.2 (2026-10-25)
+
+macOS's `/bin/bash` 3.2.57, and `/bin/sh`, which is the same bash in sh mode, close every
+inherited descriptor above stderr when started with both `-l` and `-i`, even with
+`--noprofile --norc`. Pipes a Node parent opened on 3, 9, 10 and 19 were all closed before
+the `-c` script ran. `-l` alone or `-i` alone keeps them, and so does Linux's bash 5.2.15
+(Debian, in the `node:24` image) as an interactive login shell. zsh 5.9 and ksh 93u+ keep
+them; dash keeps 3–9 but cannot name a descriptor of 10 or more, so a higher number is no
+fix. With descriptor 3 as the only channel, every probe through those shells failed `login
+shell exited with status 0 before starting the probe command` although its command ran,
+and so did `elwood`'s agent detection. Any macOS user whose login shell is bash could not
+start a session. GitHub's `macos-latest` runner user's shell is bash.
+
+The probe script now tests the write, then keeps descriptor 3 open through the e2e home
+guard (PRD §12), whose stop line takes the same path, and closes it only before the command:
+`{ echo L >&3; } 2>/dev/null || echo L; <guard>; exec 3>&-; <command>`. zsh, ksh, macOS
+and Debian dash, non-login bash 3.2 and bash 5.2 took descriptor 3 when it was open and
+stdout when it was closed, and none printed the failed redirection's error. The fallback
+is stdout, not stderr. Under real `bash -l -i` with a
+`~/.bash_profile` of `exec 2>/dev/null` or `exec 2>&1`, the line arrived on stdout and the
+probe passed. A stderr fallback would have been discarded by the first and moved into
+stdout by the second. A profile that hid stdout would hide the command's own output and
+fail the probe regardless. The runner removes the line from captured stdout. A profile
+that runs `exec 3>&-` itself now falls back too. Only a profile that reopens descriptor 3
+onto something else still loses the line. Because stdout is now watched for every probe,
+the line ends in a random per-process token: a profile that printed the bare
+`elwood-probe-command-start` would otherwise start the command's bound while the profile
+was still loading. `tests/unit/probe-closed-descriptor.test.ts` covers this with a
+`/bin/sh` stand-in that closes descriptor 3 on every host, and with real `/bin/bash -l -i`
+where `/bin/bash` is 3.x. The nine tests of its first version all fail on `main` at
+613b3ea5.
+
 ## Testing against the real CLIs
 
 - `test:e2e` runs **serially** (`--test-concurrency=1`): Codex config-file
@@ -916,6 +1838,115 @@ side-effect-free signal. C-CLI-21 through C-CLI-24.
   CLI SHOULD have a real-CLI e2e. Every fact in this file is one a unit test could
   not have caught.
 
+### Claude under a private `CLAUDE_CONFIG_DIR` (2.1.310, 2026-10-26)
+
+With `CLAUDE_CONFIG_DIR` set, Claude keeps everything there: its global config is
+`$CLAUDE_CONFIG_DIR/.claude.json` instead of `~/.claude.json`, and settings,
+`projects/` transcripts, history and backups sit beside it. `claude auth status`
+reports both paths (`configDirectory`, `projectsDirectory`). Without the variable,
+every directory Claude runs in gets an entry in `~/.claude.json` and a transcript
+folder under `~/.claude/projects/`, so each real-Claude e2e scratch project used
+to leave both behind.
+
+An empty config dir is logged out (`loggedIn: false`): Claude does not read the
+default `Claude Code-credentials` keychain item for it. It does read a
+`$CLAUDE_CONFIG_DIR/.credentials.json` holding the keychain item's JSON. A copy with
+`refreshToken` and `refreshTokenExpiresAt` removed logs in (`authMethod:
+"claude.ai"`), creates no new keychain item, and cannot refresh, so it can never
+rotate the user's own refresh token. It works until the access token's `expiresAt`,
+which is why `tests/e2e/claude-home.ts` copies it afresh in each process.
+
+A set config dir has a keychain item of its own (claude 2.1.310, 2026-10-26):
+`Claude Code-credentials-` followed by the first eight hex digits of the SHA-256 of
+the `CLAUDE_CONFIG_DIR` value as written, NFC-normalized, even when it names
+`~/.claude`. An empty value counts as unset. With `CLAUDE_CONFIG_DIR` set to a fresh
+dir, `claude auth status` reported `loggedIn: true` exactly while an item of that
+name existed. The item wins over a `.credentials.json` in the same dir: with both
+holding different logins, Claude reported the item's. So a user with the variable
+set may have their login only in that item, and `tests/e2e/claude-home.ts` reads it
+from there first. The 2.1.310 binary also lets `CLAUDE_SECURESTORAGE_CONFIG_DIR`
+replace the setting the item is named for (read from the code, not exercised). When
+it is set, even to an empty value, it decides the name: empty means the default item,
+anything else that value's hash. Only when it is unset does `CLAUDE_CONFIG_DIR` decide.
+Claude also passes the variable on to the teammates it spawns. So a Claude started with
+a private `CLAUDE_CONFIG_DIR` would still use the user's item while the variable is
+inherited. `tests/e2e/claude-home.ts` reads the user's login from the item that
+variable names, then removes it from the suite's environment.
+
+An `ANTHROPIC_API_KEY` in the environment logs any config dir in on its own
+(`authMethod: "api_key"`), so check a login with it unset. In the TUI, whether that
+key is used is the global config's `customApiKeyResponses`, which the e2e copy keeps.
+
+`ready` does not show that Claude got neither credential variable (Claude 2.1.310,
+2026-10-26). With the copied login, an invalid `ANTHROPIC_API_KEY` from the launch
+shell's startup files keeps the TUI from `ready`, but an invalid `ANTHROPIC_AUTH_TOKEN`
+does not: Claude reaches `ready` with it set. Both variables can also come from the
+developer's own startup files, after Elwood's environment is handed over. So C-E2E-23
+unsets both in the launch shell, and a `SessionStart` project hook records which of the
+two Claude's own environment holds (`tests/e2e/claude-credential-hook.ts`).
+
+The private dir carries none of the user's `settings.json`, so it shows what a fresh
+install does: the bypass-permissions dialog appears unless
+`skipDangerousModePermissionPrompt` is set (see above), and the footer shows Claude's
+default permission mode. C-E2E-23.
+
+### A rate-limited Codex turn stays running for minutes (2026-10-25)
+
+Codex 0.164.0 retries a `429 Too Many Requests` after the server's retry delay. In
+Codex's own log (`~/.codex/logs_2.sqlite`, target `codex_core::responses_retry`)
+the delay for four e2e turns on one account's default model was 110 to 509 s. All
+four retries were scheduled for the same instant, the end of a usage window. While
+it waits, Codex paints
+`• Reconnecting... 1/5 (44s • esc to interrupt)` over
+`└ Exceeded retry limit, last status: 429 Too Many Requests`. The rollout ends at
+the user message with no reply, and no `Stop` hook fires. Elwood correctly stays
+`running`, because the turn has not ended. A real-turn e2e that inherits the
+developer's `~/.codex` shares that model's limit with every Codex session on the
+account, so it can wait out a backoff no test timeout covers. A test avoids this by
+pinning a private `CODEX_HOME` and a small model. `tests/e2e/resume-ready-codex.e2e.ts`
+does, and bounds its readiness, turn and submission waits so a stuck step fails with
+its label and the screen.
+
+A private home whose `config.toml` points
+`model_provider` at a local `[model_providers.<id>]` with `base_url =
+"http://127.0.0.1:<port>/v1"` and `wire_api = "responses"` reproduces this
+without quota. That provider answers every request with 429 and `retry-after: 300`.
+Codex still lists models from it before the first turn. C-API-28.
+
+### Concurrent cold starts race Codex's state migrations (2026-10-25)
+
+Codex 0.164.0 creates and migrates its SQLite state under `CODEX_HOME` at launch
+(61 migrations in `state_5.sqlite`, 2 in `goals_1.sqlite`), and nothing serializes
+those migrations across processes. When two Codex processes start together in a home
+whose databases are not yet migrated, both try to apply the same migration. The loser
+exits 1 with `Codex couldn't start because its local database appears to be damaged`,
+and the cause names the collision, such as `table thread_goals already exists` or
+`duplicate column name`. Six different migrations collided across the runs below. The
+exit landed 2 to 10 s after spawn. In every Elwood run that was after `startCodex` had
+resolved, so Elwood reported `running` → `exited` (`terminal_exited`) and the session
+never reached `ready`.
+
+C-CODEX-14's e2e started its two sessions with `Promise.all` in a fresh sandbox. The
+same start lost a session in 4 of 5 probes and in 5 of 6 e2e runs. The test's readiness
+poll then ran out its full minute, and the surviving session, which `Promise.all`
+dropped, kept the test file running. Replaying Elwood's exact launch command through a
+bare node-pty, with no Elwood code, crashed one of the two in 3 of 4 runs. One launch
+alone never crashed. Bare pairs with only `--sandbox`, `--ask-for-approval`, and `--cd`
+never crashed in 16 runs. Adding `-c model_reasoning_effort="low"` alone or
+`--dangerously-bypass-hook-trust` alone crashed 3 of 3, and `-c features.hooks=true`
+alone crashed 0 of 3. The runs do not show why the bare pairs escaped, so treat any
+pair of simultaneous launches as exposed.
+
+A single launch at load 50 finished every migration about 1.5 s after spawn, as its
+composer painted. The composer does not prove migration is done: a launch killed one
+second after its composer appeared left migrations for the next pair, which raced in 1
+of 4 runs. The e2e now starts the second session after the first reports `ready`, which
+on a cold start is the 10 s deadline from the first frame. The concurrency it tests is
+the model switch.
+
+Production homes already hold migrated databases. The exposure is the first launch of
+a Codex release that adds a migration, if several sessions start at that moment.
+
 ### Codex commentary and final-answer phases (2026-10-20)
 
 The reported completed `response_item` fixture retains assistant text in an
@@ -955,6 +1986,17 @@ partial model dialog is insufficient. The sanitized Claude frame is retained in
 `tests/fixtures/claude-2.1.278/model-cancelled.txt`. With this recognition fix,
 Claude also completed automated `listModels` and returned five rows (C-API-55).
 
+### Idle CLIs do not repaint (2026-10-25)
+
+A probe started real sessions through Elwood, waited for `ready` plus 3 s, and then
+counted PTY output chunks while the session sat idle. Codex 0.164.0 emitted none in
+15 s idle, and none in the 10 s after `listModels` opened and cancelled its picker.
+Claude Code 2.1.310 emitted one chunk in each window. Clearing a model-dialog hold
+therefore cannot wait for a run of new frames, because on Codex none arrive. The
+evidence has to be the same completed frame read over time. Readings count at
+least 40 ms apart, so neither bunched readings nor a fast burst of repaints can
+release a hold early (C-API-55).
+
 
 ### Cursor provenance for Codex trust clearance
 
@@ -979,6 +2021,13 @@ only the production clear write made both tests retain the image and text and fa
 This verifies an automation-owned idle composer, not cleanup across caller edits
 or blocking dialogs. Codex clipboard text is restored after attachment.
 
+codex-cli 0.164 (2026-10-26) saves the pasted image as `codex-clipboard-<suffix>.png`
+in its temp dir when the `[Image #1]` chip appears, and clearing the draft leaves that
+file in place. The draft is never submitted, so no transcript names the copy, and a
+session removes only the copies its transcript names. So a cancelled Codex image draft
+leaves its copy in the temp dir. `composer-cleanup.e2e.ts` gives its Codex a `TMPDIR`
+inside the sandbox home, asserts the copy lands there, and removes it with the sandbox.
+
 
 Native startup protocol replies also emit xterm `onData`. The actual-session
 image-cancellation proof exposed this on both adapters: treating those replies as
@@ -1167,6 +2216,41 @@ bounds, not acceptance or post-acceptance behavior. The temporary Codex auth
 copy was removed after teardown.
 
 
+## Claude's temp root (Claude 2.1.310, 2026-10-26)
+
+Claude keeps its temp files under a root: `CLAUDE_CODE_TMPDIR` when set, else `/tmp`, so
+the macOS `TMPDIR` does not move it. Measured with real sessions started through Elwood:
+
+- Under `<root>/claude-<uid>/`, Claude makes one folder per working directory, named for
+  the directory's real path with each character other than a letter or digit replaced by
+  `-`. It holds a folder per session with that session's `scratchpad/`. The folder is
+  still there after `stop()` and after `teardown()`; nothing in Claude removes it. Every
+  e2e scratch project left one in the shared `/tmp/claude-<uid>` until the suite gave each
+  e2e process a private `CLAUDE_CODE_TMPDIR` (C-E2E-23).
+- Claude's messaging socket is `<root>/cc-socks/<pid>.sock`. The 2.1.310 bundle uses that
+  path only while it is at most 103 bytes, and otherwise falls back to
+  `/tmp/cc-socks-<uid>/<pid>.sock`, so a long root moves the socket back into the shared
+  `/tmp`. The e2e root's prefix is short for that reason.
+- Claude, run directly in a PTY, removes its socket when it exits on SIGTERM, SIGHUP,
+  `/exit`, or Ctrl-C. A SIGKILL leaves it: after `teardown()`, which SIGKILLs a live session,
+  `/tmp/cc-socks/<pid>.sock` remained for the dead pid. After `stop()`, whose SIGTERM
+  Claude exits on, it did not.
+
+## Codex keeps a temp copy of every pasted image (codex-cli 0.164.0, 2026-10-26)
+
+On Ctrl+V with an image on the clipboard, Codex writes the image to
+`$TMPDIR/codex-clipboard-<suffix>.png` before the `[Image #N]` chip appears, and nothing
+in Codex ever removes it: a real attach left the file in place after the turn finished
+and after `teardown()`. The suffix is six random characters on 0.164.0; an earlier
+rollout on the same machine names a UUID form (`codex-clipboard-<uuid>.png`). When the message is submitted,
+the rollout records the path twice: as `{"type":"local_image","path":...}` in the
+content of an `event_msg` `item_completed` `UserMessage`, and as
+`<image name=[Image #1] path="...">` text beside the inline `input_image` data in the
+`response_item` message. The image itself travels inline, so nothing reads the file
+after submission. Once the CLI exits, Elwood removes the copies the session's transcript
+names directly in Elwood's own temp directory (C-API-46). A Codex whose login shell sets
+another `TMPDIR` keeps its copies there, and Elwood does not remove them.
+
 ## Cached image recovery frames (2026-10-01)
 
 The existing captured image-chip and staged-text layouts establish live composer
@@ -1234,6 +2318,78 @@ profile timed out before `codex --version` at 15 seconds; the same pinned binary
 with an empty private profile directory returned its version in 52 ms. This
 preflight failure submitted no model turn. Parent environment values stay intact.
 
+### Claude named-session composer rule (2026-10-24)
+
+`claude --name` (Elwood's `name` option; Coal Harbor names every agent) insets the
+name into the composer's top rule on Claude Code 2.1.310: `──── Question Asker ─`.
+The rule below the composer stays plain, and the terminal title becomes
+`✳ Question Asker` instead of `✳ Claude Code`. Composer recognition required plain
+rules on both sides, so trust clearance and empty-input observation never matched a
+named session. In an untrusted folder, autotrust answered the trust prompt but the
+session stayed `blocked` on the idle composer; in a trusted folder it reached `ready`
+through hooks and hid the gap. The top rule may now carry one inset label
+(`src/claude/composer/border.ts`). See `tests/fixtures/claude-2.1.310/`.
+
+### Claude permission-mode footers (2026-10-25)
+
+Startup-only captures from Claude Code 2.1.310 launched with each
+`--permission-mode`, with no model prompt sent. The footer is the row directly
+under the composer's bottom rule. With the developer's settings
+(`editorMode: "vim"`, `verbose: true`):
+
+```
+-- INSERT -- ⏸ manual mode on · ← for agents                        0 tokens
+-- INSERT -- ⏸ plan mode on (shift+tab to cycle) · ← for agents     0 tokens
+-- INSERT -- ⏵⏵ accept edits on (shift+tab to cycle) · ← for agents  0 tokens
+-- INSERT -- ⏵⏵ auto mode on (shift+tab to cycle) · ← for agents    0 tokens
+-- INSERT -- ⏵⏵ don't ask on (shift+tab to cycle) · ← for agents    0 tokens
+-- INSERT -- ⏵⏵ bypass permissions on (shift+tab to cycle) · ← for agents  0 tokens
+```
+
+The effort level (`● high · /effort`) sits on the next row. With
+`editorMode: "normal"` and `verbose: false` (passed through `--settings`, never
+written to user config) there is no `-- INSERT --` and no token count, and the
+effort level moves to the footer's right edge:
+`⏸ manual mode on · ? for shortcuts · ← for agents   ● high · /effort`. Only
+manual mode lacks `(shift+tab to cycle)`, and in this layout only manual mode
+shows `? for shortcuts`. A `default` launch renders `manual mode`. Vim normal mode,
+after an Escape at the idle composer, drops the `-- INSERT --` prefix. Each
+effort level has its own glyph: `○ low`, `◐ medium`, `● high`, `◉ xhigh`,
+`◈ max`. The captures only show `0 tokens`. The binary formats counts with
+`Intl.NumberFormat` compact notation, then lowercases them: `999`, `1.0k` (or
+`1k` where it strips `.0`), `12.3k`, `2.1m`. Counts are never digit-grouped.
+
+Some pieces are transient. Release notes embedded in the 2.1.310 binary say
+`← for agents` hides 10 seconds after a session opens. In the captures it was still present at 13 s
+and gone by 27 s. Late frames also lost the effort level: no effort row in the
+vim layout, an empty right edge in the plain one.
+
+Elwood accepted only the 2.1.278 auto and don't-ask footers with the agents hint
+and no right edge, plus the 2.1.305 manual footer. On 2.1.310 only the late
+plain manual footer, identical to 2.1.305's, still matched. Trust clearance then depended on the version banner, which
+scrolls out of the viewport in a long session. Model-picker hold release never
+saw the banner at all, because it reads only the last composer and the rows
+beneath it. Empty-input observation rejected every 2.1.310 effort row. The shared
+grammar is `src/claude/composer/footer.ts`, and trust clearance requires the
+footer directly under the bottom rule, so a quoted footer cannot pass for chrome.
+Empty-input observation requires the same row. None of the 159 composer frames
+captured on 2.1.310, and none in the 2.1.278 to 2.1.305 fixtures, has a blank row
+between the bottom rule and the footer. Overflow rows and the login-renewal notice
+only ever follow the footer.
+Sanitized 100x8 bannerless frames for every mode are in
+`tests/fixtures/claude-2.1.310/mode-footers/`. `tests/e2e/permission-footer-claude.e2e.ts`
+checks a real bypass-permissions session. C-TRUST-01, C-API-55, C-API-56.
+
+Narrow terminals are not covered. Below roughly 64 to 90 columns, depending on the
+mode and layout, Claude cuts the footer mid-hint, sometimes with an ellipsis:
+`⏵⏵ bypass permissions on (shift+tab to`, `(shift+tab to cycle) · ← fo…`,
+or just `⏵⏵ bypass permissions`. It also moves the token count and effort level
+onto their own rows. A cut footer does not prove the composer, so the hold stays
+until the terminal is widened. The hand-opened 2.1.310 picker itself
+(`● High effort ←/→ to adjust`, a `↓ 8.` scroll marker, `… +5 models`) falls
+outside the model-dialog grammar on `main` at the time of writing, so that
+grammar is the remaining gap before a foreign hold engages on it.
+
 ## Claude question editor captures (2026-10-20)
 
 Claude Code 2.1.305 accepts a single question on Enter. Grouped questions advance
@@ -1254,6 +2410,24 @@ the highlighted option glyph. The captures used private configuration and
 authentication copies with synthetic prompts; see
 `tests/fixtures/claude-2.1.305/questions/`.
 
+### Claude 2.1.310 question chip and named-session border (2026-10-24)
+
+Claude Code 2.1.310 renders a single question's header chip as ` ☐ Test pick `:
+the highlight's right padding is a written trailing space, so the terminal row
+keeps it. 2.1.305 rendered ` ☐ Note` with no padding. Exact equality on the tab
+row therefore rejected every single-question panel on 2.1.310, and Elwood never
+raised the request even though the native dialog was on screen. The pinned
+2.1.305 proof could not see it. Tab matching now ignores trailing whitespace
+only; the leading space and the header text still have to match exactly.
+
+A session launched with `--name` (Coal Harbor names every agent) draws its label
+into the prompt box's bottom border — `──── Question Asker ─` — and that border
+stays one row under the questionnaire footer. The rule above the header chip
+stays plain. The questionnaire grammar used to require nothing but blank rows
+after the footer, so it rejected every question in a named session. It now
+accepts exactly one labelled border there and still rejects anything else. See
+`tests/fixtures/claude-2.1.310/questions/`.
+
 ### Claude question dialogs and manual composer (2026-10-20)
 
 Claude Code 2.1.305 renders `AskUserQuestion` as a fenced questionnaire with
@@ -1389,3 +2563,19 @@ Queued editors after the first use `⇧→ prev question`; only the first uses
 frames. If a local skip and Esc collapse coalesce into one output render, the
 smaller badge does not identify the removed question. Preserve the prior focused
 editor count until a matching remaining editor confirms that removal.
+
+## Login-shell not-found handlers (2026-10-26)
+
+A probe runs its CLI through the user's interactive login shell, so a CLI missing
+from PATH meets whatever not-found handler the startup files define. zsh 5.9 runs
+`command_not_found_handler` and bash 4.0 and later run `command_not_found_handle`.
+Ubuntu's `/etc/bash.bashrc` defines the bash one when the `command-not-found`
+package is installed, to suggest a package. The handler's
+output goes to the shell's stdout and stderr, which a probe captures, and the
+handler's return status becomes the probe's. One that returns 1 turns "not found"
+(127) into an ordinary failure. Measured with a handler printing a marker: zsh 5.9
+on macOS, and bash 5.2.37 in a Debian trixie container, both captured the marker
+and reported the handler's status. macOS's bash 3.2 predates the hook. The probe
+script now runs `unset -f command_not_found_handler command_not_found_handle
+2>/dev/null || :` before its command. Each shell ignores the other's name. With it,
+both shells exit 127 and capture no marker.