State the Captain decision per provider adapter #233

Crews are proposed from Codex and Claude threads; both adapters have explicit appends so propose_crew and the other J5 verbs get through (FORK.md, saved-agent mentions paragraph). Nothing in crews.md, agent-tools.md, or the adapters records a decision for Cursor, Grok, OpenCode, or Antigravity threads acting as Captain. AGENTS.md requires a decision per adapter, even when the decision is "not supported here". Seats on those harnesses are already handled by the runtime preview's ACP access rules; this is only about a thread on one of them proposing a Crew.

Blocked on my decision, which I will record on this issue: whether the rule for this release is "Codex and Claude Captains, any harness for seats", or whether the other adapters should be able to propose.

What should change once decided:

• Verify per adapter whether the t3-code MCP server and T3_CODE_ORCHESTRATION_INSTRUCTIONS reach the thread and whether the adapter's approval model lets a non-read-only MCP call like propose_crew through.
• Write the ruling into crews.md (Definition and AC5) and the Crews section of docs/user/personas.md.
• If an adapter needs an appended spread like Codex's J5_CODEX_T3_MCP_SERVER_CONFIG, file that as its own issue and record the append in FORK.md; do not bundle it here.

Done when crews.md states, for every provider T3 Code ships, whether a thread on it can be a Captain.

Related criteria: crews.md AC5.

Dependencies: blocked on the decision below. No code issue depends on this one.

Edit (2026-09-24, after the upstream sync in #256)

The question still stands, but the adapter list and part of the verification step are out of date.

Adapters this build ships (apps/server/src/provider/builtInDrivers.ts): Codex, Claude, Cursor, Grok, OpenCode, Antigravity, Pi, and ACP registry harnesses (Devin among them). Pi came in with the upstream sync, and its thread adapter is orchestration-v2/Adapters/PiAdapterV2.ts. The ruling has to name all eight, not four.

What the code already answers. Every adapter now gets the t3-code MCP server and the orchestration instructions, so reachability no longer needs checking one adapter at a time:

• Cursor: cursorMcpServers in CursorAdapterV2.ts
• OpenCode: OpenCodeAdapterV2.ts
• Grok, Antigravity, and ACP registry: the t3 acp-mcp-bridge stdio server in AcpAdapterV2.ts, which all three are built on
• Pi: the injected extension in piT3McpExtensionSource.ts / piT3McpInjection.ts

What is still open. Only Codex (J5_CODEX_T3_MCP_SERVER_CONFIG) and Claude (J5_CLAUDE_MCP_ALLOWED_TOOLS) pre-approve the J5 verbs. On the other six, propose_crew falls through to the harness's own approval model. It may raise a native approval card, or it may be refused in read-only or never-style modes. Pi, for example, leaves permission policy to extensions. crews.md AC5 says filing a proposal "works under every sandbox and approval policy", which today is only true on Codex and Claude.

Revised steps once decided:

• Codex and Claude only: write the rule into crews.md (Definition and AC5), naming all eight adapters. Narrow AC5 to Codex and Claude, and add the rule to the Crews section of docs/user/personas.md. No code.
• Other adapters too: for each of Cursor, Grok, OpenCode, Antigravity, Pi, and ACP registry, record how the harness handles an unapproved propose_crew in each runtime mode. File a separate issue, with a FORK.md append, for any adapter that needs a pre-approval spread like Codex's or Claude's. Update AC5 to match what is measured.

Edit (2026-09-24): decision

Ruling: every adapter can be a Captain. The "Codex and Claude only" option no longer applies.

What this issue now covers:

• For Cursor, Grok, OpenCode, Antigravity, Pi, and ACP registry, record how an unapproved propose_crew is handled in each runtime mode. Work it out from the adapter and harness code first, then spot-check live on the harnesses installed here (isolated dev server, copied data). Mark each result as measured or derived from code.
• The rule: the roster gate is the only human step. An adapter that raises a native prompt or refuses needs a pre-approval append for the full J5 set in J5_CODEX_PREAPPROVED_TOOLS, not only the crew verbs.
• File one issue per adapter that needs an append, in this milestone, each recording its append in FORK.md. The appends are not done here.
• Write the ruling into crews.md (Definition and AC5) and the Crews section of docs/user/personas.md: every shipped adapter can be a Captain. Until an adapter's append lands, the docs say which adapters still show an extra prompt, or refuse, before the roster gate.

Done when crews.md names all eight adapters as Captain-capable and every adapter that needs an append has its own issue.

Edit (2026-09-24): where pending adapters are listed

docs/j5/process/docs.md requires a definition to describe the end state, so crews.md (Definition and AC5) says only that every shipped adapter can be a Captain and that the roster gate is the only human step. The pending adapters are tracked in their own issues, not in crews.md. docs/user/personas.md describes what ships today, so it names the harnesses that still show an extra prompt, or refuse, before the roster gate. Each adapter PR narrows that list, and the last one removes the sentence.

Edit (2026-09-24): pre-approval matches Codex per mode

Every adapter pre-approves exactly what Codex pre-approves in the same mode. Where the harness would never ask (Codex's approval policy never: full access, and saved-persona policies that resolve to it), that is the full set in J5_CODEX_PREAPPROVED_TOOLS. In the interactive modes (approval-required, auto-accept-edits, auto), it is only send_message, clear_own_ask, propose_crew, and request_crew_member. Every other tool keeps the harness's own verdict. Codex itself is unchanged, and no harness pre-approves more than Codex in any mode. Both sets and the mode-to-set rule live in one J5-owned module that Codex's j5CodexT3McpServerConfig and every new adapter append share.