bryantderosier · Sep 29, 2026 · Sep 25, 2026 · Sep 25, 2026 · Sep 28, 2026 · Sep 28, 2026
diff --git a/apps/server/src/j5/a2a/CrewProposalService.ts b/apps/server/src/j5/a2a/CrewProposalService.ts
@@ -644,7 +644,8 @@ export const layer = Layer.effect(
           const resolved = yield* resolveRuntime(captain, seats);
           if (input.approvalToken !== crewApprovalToken(proposal, captain, resolved))
             return yield* new CrewProposalRequestError({
-              detail: "The crew runtime preview is missing or has changed since it was shown.",
+              detail:
+                "The crew runtime preview is missing or has changed since it was shown: the roster, a seat's runtime, or the Captain's branch or worktree may have changed.",
               nextStep: "Refresh the preview and review the current settings before approving.",
             });
           const launched = yield* fulfil(proposal, captain, seats, resolved);

diff --git a/docs/j5/product/features/crews.md b/docs/j5/product/features/crews.md
@@ -49,7 +49,7 @@ The platform ships the machinery — propose, gate, spawn, render, remind, notif
 
 1. Asking for a Crew in ordinary chat causes the current agent to propose a roster before doing the delegated work. The thread retains its persona, model, and policy; saved personas are optional and there is no Crew slash command.
 2. A roster proposal renders inline above the Captain's composer; the person can remove seats, add personas from the library or a custom seat (Custom crew member is the first choice; it takes a name and required instructions, and exposes editable harness, model, reasoning, and access controls), then approve the final roster or decline.
-3. Initial roster and Inbox addition cards show every seat's saved definition or custom-seat choice, instructions, harness, model, reasoning level, and access; the Captain's reason for a seat is read in that seat's edit dialog. A seat whose access will stop for approvals (anything short of Full access, other than a saved persona on its own policy) is flagged, and the card counts them. Editing the roster or any member’s runtime setting refreshes the server preview. Missing, unavailable, or stale previews cannot approve a launch; approval launches the exact validated runtime configuration, including advertised defaults.
+3. Initial roster and Inbox addition cards show every seat's saved definition or custom-seat choice, instructions, harness, model, reasoning level, and access; the Captain's reason for a seat is read in that seat's edit dialog. A seat whose access will stop for approvals (anything short of Full access, other than a saved persona on its own policy) is flagged, and the card counts them. Editing the roster or any member’s runtime setting refreshes the server preview. The preview also binds the Captain's project, branch, worktree, and interaction mode, so changing any of them needs a fresh preview. Missing, unavailable, or stale previews cannot approve a launch; approval launches the exact validated runtime configuration, including advertised defaults.
 4. A seat naming an agent missing from or disabled in the library, a duplicate seat name, or a roster past twelve seats is refused to the Captain with the next step, before anything spawns; prose is never parsed.
 5. Filing a proposal or a seat request is itself the human gate. On Codex and Claude, under every sandbox, approval policy, and runtime mode, including Codex approval policy `never`, `propose_crew`, `request_crew_member`, `send_message`, and `clear_own_ask` reach the gate or their recipient with no other human step and are never refused. On every other shipped harness they may first raise that harness's own MCP prompt once, and a read-only persona there cannot propose. Where the thread never asks for approval (full access, or a saved persona whose policy resolves to never), spawning, stopping, and archiving, `write_artifact`, and the delegated-task verbs also run without a prompt; in interactive modes the harness's own approval may apply to them.
 
@@ -119,6 +119,7 @@ The platform ships the machinery — propose, gate, spawn, render, remind, notif
 - 2026-09-25 — a Crew follows its Captain: there is never a Crew without its Captain, so a Captain's unarchive brings back the Crews that retired with it, and settling or unsettling the Captain does the same to its seats, leaving a seat that is still running or waiting on the person; archive and delete keep cascading and keep their boot sweep, each Crew's step runs once, and a seat is still never archived on its own. Because the unarchive now brings the Crews back, a Captain's archive offers upstream's Undo like any other. This replaces the earlier plan for #312 to let an archive touch one agent (Bryant; [#312](https://github.com/Jacksondr5/j5code/issues/312)).
 - 2026-09-16 — `/crew` decoupled from the `crew-captain` saved agent: the command sends the brief with the platform's crew-composition guidance to whatever agent the thread runs as, from a fresh draft or an existing thread, and the bundled example is retired; a Captain may command several Crews at once, each a named, collapsible group with its own Stop on the sidebar expander (Bryant; [record](../../worklog/2026-09-16-crew-command-decoupling.md)).
 - 2026-09-24 — every shipped provider can be a Captain, not only Codex and Claude. J5 pre-approves its tools on Codex and Claude, where the roster card is the only human step before launch; other harnesses may ask once with their own MCP prompt first, and a read-only persona there can't propose (Jackson's ruling on [#233](https://github.com/Jacksondr5/j5code/issues/233), 2026-09-26). On Codex and Claude the rest of the platform's verbs are pre-approved per mode, freely where the thread never asks for approval.
+- 2026-09-24 — AC3 states that the approval preview binds the Captain's project, branch, worktree, and interaction mode, so a branch switch needs a fresh preview (Bryant; [#231](https://github.com/Jacksondr5/j5code/issues/231)).
 - 2026-09-24 — the J5 document is named "handoff artifact" to distinguish it from upstream's context handoffs.
 - 2026-09-26 — a seat's provider tool approvals are answerable from the Inbox as well as its thread; the Captain's approvals and questions stay inline in the thread the person watches (Jackson; [#263](https://github.com/Jacksondr5/j5code/issues/263), [#264](https://github.com/Jacksondr5/j5code/issues/264)).
 - 2026-09-26 — seats get no native question tools: a seat that needs a decision asks its Captain with `send_message`, and the Captain answers or asks the person inline in its own thread; Claude seats lose `AskUserQuestion` and Codex seats `request_user_input`, other harnesses get the instruction only (Jackson; [#325](https://github.com/Jacksondr5/j5code/issues/325)).

diff --git a/docs/user/personas.md b/docs/user/personas.md
@@ -46,7 +46,7 @@ A crew is a group of agents that one agent, the Captain, runs as a unit for one
 
 > Put together a crew to follow @docs/runbooks/release.md for the 2.4 release and report back when the PR is green.
 
-The agent uses the conversation to propose a roster above the composer. Each member has a responsibility, a reason for joining, and instructions. Members may use saved personas or be custom agents created for this task. You can remove members, add a saved persona, or add a custom seat with a name and instructions, then approve or decline. Custom members start with the Captain's harness, model, and reasoning level, and with Full access. Before approval, you can change their harness, model, reasoning level, and access, whether the agent proposed the member or you added it manually. Selecting a saved persona uses that persona's configured runtime policy. No special Captain persona is needed, and one Captain can coordinate several crews in the same conversation. Before you approve, each member shows its resolved harness, model, reasoning level, and access. Members whose access asks before acting are marked **Stops for approvals**: they pause in their own threads until you answer, so give them Full access if you will not be watching. Changing the roster refreshes these details. If the configuration changes before launch, review the refreshed settings and approve again.
+The agent uses the conversation to propose a roster above the composer. Each member has a responsibility, a reason for joining, and instructions. Members may use saved personas or be custom agents created for this task. You can remove members, add a saved persona, or add a custom seat with a name and instructions, then approve or decline. Custom members start with the Captain's harness, model, and reasoning level, and with Full access. Before approval, you can change their harness, model, reasoning level, and access, whether the agent proposed the member or you added it manually. Selecting a saved persona uses that persona's configured runtime policy. No special Captain persona is needed, and one Captain can coordinate several crews in the same conversation. Before you approve, each member shows its resolved harness, model, reasoning level, and access. Members whose access asks before acting are marked **Stops for approvals**: they pause in their own threads until you answer, so give them Full access if you will not be watching. Changing the roster refreshes these details. If the configuration changes before launch, review the refreshed settings and approve again. The preview also covers the Captain's branch and worktree, so switching the Captain's branch before you approve means reviewing a fresh preview. A member on an ACP registry harness offers only **Supervised** and **Full access**, because those harnesses can't enforce **Auto-accept edits** or **Auto**.
 
 A conversation on any harness can propose a crew. On **Codex** and **Claude**, approving the roster is the only confirmation you give. Other harnesses may show their own approval prompt once before the roster, and a conversation running as a saved persona with read-only access can't propose a crew on them. Two cases differ: