fix: prevent Codex and Pi folder-trust stalls in pooled worktrees

.agents/skills/harness-adapters/references/common/control-and-recovery.md

@@ -21,8 +21,7 @@ For Claude, load `references/harness/claude.md`; its workspace-trust section own
 agy gates every fresh worktree too; the spawn pre-registers it in agy's own store the same way, and a strict post-launch gate answers any dialog that still renders before the spawn reports success.
 Cursor suppresses its dialog with launch-time `--trust`, and Muse suppresses its own with `--yolo`.
 Grok renders a folder-trust gate in a linked worktree, and `references/harness/grok.md` owns how to verify the worker's real location, answer it, and where the decision persists; the project picker is a separate dialog that stays absent when the spawn starts in a git root.
-Pi gates the fresh-worktree case too, but unlike Claude its dialog is answered with Enter, and `references/harness/pi.md` owns that recipe and where the decision persists.
-Codex shows a directory-trust dialog on the first run for a repository root.
+For Pi and Codex, `references/harness/pi.md` and `references/harness/codex.md` own automatic folder approval and the attended-checkout boundary.
 
 Use the tool's exact skill form, or natural language only when no separate command is verified or the form remains uncertain.
 A successful send or key return is not proof of submission; require the tool-specific postcondition.

.agents/skills/harness-adapters/references/harness/codex.md

@@ -16,9 +16,13 @@ Verified on 2026-06-11 with codex-cli 0.139.0 unless a fact gives a newer versio
 | Model discovery | Open the current interactive session's `/model` picker. |
 | Marker | None; identity comes from ancestry, and `../../../bin/fm-harness.sh` is what keeps a retained foreign `CLAUDECODE` from renaming it. Verified on 2026-09-01 with codex-cli 0.152.0: the pane process is the `node` npm shim and the native `codex` binary runs as its foreground child, so a tool subprocess reaches the native name directly while the shim itself is identified from its script path. |
 
-A directory trust dialog appears on the first run for a repository root: "Do you trust the contents of this directory?"
-Accept it with Enter and verify the instructions begin processing.
-The decision persists for the repository, so later worktrees of the same project skip it.
+A directory trust dialog appears on the first run for a repository root: "Folder access … Trust this folder?", with "Trust and continue" already selected and "Quit" second.
+Saved folder approval covers the canonical repository root and its worktrees; `../../../bin/fm-codex-trust.sh` owns the store format and registration safeguards.
+For a qualifying linked pool worktree, `../../../bin/fm-spawn.sh` requires successful registration through `../../../bin/fm-codex-trust.sh` before launching Codex, so registration failure stops the launch and successful registration removes the folder prompt.
+Secondmate seed markers do not grant folder trust: both registration modes require a linked pool worktree, while standalone and other attended checkouts keep manual folder approval.
+For an attended checkout, accept the selected "Trust and continue" option with Enter and verify the instructions begin processing.
+Bounded read-to-replace race: an independent writer can still add a distinct project's trusted entry after the final read and before replacement; losing that entry causes a recoverable folder re-prompt, without losing project data or granting trust to another project.
+The [maintainer verification record](../../../../../docs/verification/runtime-backends.md#folder-and-project-trust-on-a-fresh-worktree) owns versioned vendor observations and the live refresh command.
 
 ## Hook trust
 

.agents/skills/harness-adapters/references/harness/pi.md

@@ -30,10 +30,14 @@ The router's Detection section owns how launch markers and ancestry select betwe
 Keep the instructions as one positional argument.
 Multiple positional arguments become separate queued messages; the spawn template already preserves the one-argument shape.
 
-A project trust dialog can appear on the first Pi run in any not-yet-trusted directory that holds a trust-requiring resource such as `.pi/extensions/`, including a clean worktree and a freshly seeded secondmate home.
-Accept it with Enter and verify the instructions begin processing.
-The decision persists per path in `~/.pi/agent/trust.json`, or in the pinned root's `trust.json` under a worker account pin, so later spawns in the same pooled slot under that root skip it.
-For unattended seeded-secondmate launches, `../../../bin/fm-spawn.sh --help` owns the capability-gated project-trust approval mechanics; [runtime verification](../../../../../docs/verification/runtime-backends.md#pi-seeded-secondmate-project-trust) owns the regression evidence.
+A project trust dialog can appear on the first Pi run in any not-yet-trusted directory, including a clean worktree: "Trust project folder?", offering Trust, Trust parent folder, Trust (this session only), Do not trust, and Do not trust (this session only), with the cursor on Trust.
+Saved decisions are keyed per canonical directory with a walk up through the parents, the closest one winning, in `<$PI_CODING_AGENT_DIR or ~/.pi/agent>/trust.json`.
+For a qualifying linked pool worktree, both canonical and raw launch commands for ships, scouts, and local secondmates carry Pi's own `--approve`, a per-run decision consulted before saved decisions that persists nothing.
+Secondmate seed markers do not grant folder trust: both Pi identities require a linked pool worktree for `--approve`, while standalone and other attended checkouts keep manual folder approval.
+For an attended checkout, accept the selected Trust option with Enter and verify the instructions begin processing.
+Approval loads the directory's `.pi` resources and project extensions for that run.
+The [maintainer verification record](../../../../../docs/verification/runtime-backends.md#folder-and-project-trust-on-a-fresh-worktree) owns versioned vendor observations and the live refresh command.
+The store's per-directory scope is why a launch flag is the right shape here rather than a pre-registered entry: a pooled worktree path would otherwise add one store entry per slot, and a worker account pin relocates that store, so a writer would have to resolve the pin first.
 
 ## Worker turn-end extension