feat(crews): seats ask their Captain instead of the person

[bryantderosier]

Important

⚠️ Merge order: merge these in this exact order

1. feat(crews): a Crew thread's provider approvals and questions reach the Inbox API #308: seat approvals reach the Inbox API
2. feat(crews): answer a Crew thread's provider approvals and questions from the Inbox #309: the Inbox shows seat approvals
3. This PR ⬅️ — ship it with feat(crews): answer a Crew thread's provider approvals and questions from the Inbox #309, since feat(crews): a Crew thread's provider approvals and questions reach the Inbox API #308/feat(crews): answer a Crew thread's provider approvals and questions from the Inbox #309 no longer cover seat questions

Problem

A Crew seat that raised a native question (Claude's AskUserQuestion, Codex's request_user_input) blocked in its own thread, which nobody watches. Jackson's decision on #325 is that seats don't get native question tools: a seat asks its Captain, and the Captain answers or asks the person inline. #308/#309 were slimmed to seat approvals on the same assumption, so without this a seat question stalls the Crew.

What I changed

• apps/server/src/j5/a2a/crewSeatRuntime.ts → makeCrewSeatLookup / withCrewSeatQuestions, J5-owned and wired in through agentPersonaRuntime.ts (already behind upstream RuntimePolicy.ts):
  • A thread created as an agent or MCP thread that sits in a live Crew gets crewSeat: true.
  • It also gets a seat rule appended to agentPersonaInstructions: "questions go to your Captain" with send_message and expect_reply=true.
  • A store that can't be read logs a warning and treats the thread as no seat.
• Claude: ClaudeAdapterV2.ts → openQuery passes disallowedTools: ["AskUserQuestion"] for seats only.
• Codex: CodexAdapterV2.ts → codexThreadRuntimeParams adds J5_CODEX_CREW_SEAT_CONFIG to the thread config next to mcp_servers: "features.default_mode_request_user_input": false and "tools.experimental_request_user_input.enabled": false. They're dotted keys, so the user's own [features]/[tools] tables stay intact.
• ProviderAdapter.ts: an optional crewSeat flag on the runtime policy.
• spawnIds.ts → spawnFirstTurnText: the seat brief's <crew_collaboration> says to ask the Captain, never the person or a native question tool.
• Other harnesses (Cursor, Grok, OpenCode, Pi, ACP registry agents, Antigravity): not supported on seats yet. Only the brief's instruction applies, and crews.md records that per harness.
• FORK.md case 47 covers the three upstream adapter appends and the policy field, with file-table rows.
• Docs: crews.md (Definition, AC9, History) and the Crews section of docs/user/personas.md.

Why this shape

• Seat detection lives in the runtime-policy resolver. That resolver already hands J5 persona instructions to both adapters, so each adapter needs only one line. The rule text is appended after Codex's Default-mode "ask the user directly" text, so the upstream developer instructions stay untouched.
• Codex keys: I found them in the Codex binary and confirmed them against a live app-server; see Verification.

Invariants

• Only live-Crew seat threads lose native question tools. Captains and every other thread keep them.
• The seat rule and the Codex config come from one J5 helper, so a key change is one edit (J5_CODEX_CREW_SEAT_CONFIG).

Surfaces

Surface	Decision
Entry points (chat, Settings, command palette, keybinding)	Unaffected; this is how seats run.
Clients (web, desktop, mobile)	Unaffected.
Providers	Claude and Codex seats lose native question tools. Others are not supported on seats yet; the brief instruction applies.
Contracts (packages/contracts)	Unaffected.
Reverse states	A seat's Crew retiring makes it an ordinary thread again, with its question tools back.
Connection modes (local, remote, tunnel)	Unaffected.
Upstream files / FORK.md	ClaudeAdapterV2.ts, CodexAdapterV2.ts, ProviderAdapter.ts (plus the Claude adapter test), recorded as case 47.
Docs	Changed: crews.md, personas.md.

Out of scope

• Claude seats can still use ExitPlanMode, which isn't a question tool. Its plan approval would still be asked in the seat's own thread.
• Merge note: spawnBriefWithoutCrewContext (touched here to ignore <crew_collaboration> in brief comparisons) is deleted by fix(crews): a proposal launches once and reports every seat #313. Whichever of the two stacks lands second drops this hunk.

Upgrade and data

None. Existing seats pick up the rule on their next session start.

Verification

• apps/server, apps/web, and packages/contracts typecheck (exit 0). vp test run apps/server/src/j5 apps/web/src/j5 apps/server/src/orchestration-v2/Adapters: 1,564 passed, 1 skipped. Lint is clean.
• New tests:
  • A seat is flagged and gets the rule; a Captain, a person's thread, and a seat in an archived Crew are not.
  • A seat's Codex config carries both keys and a Captain's doesn't.
  • The Claude adapter withholds AskUserQuestion only from a seat. This test fails with the adapter line removed.
  • The seat brief wording.
• Live Codex check: Codex CLI 0.155.1, codex app-server driven over stdio the way the adapter does, a Default-mode collaboration setting, and a throwaway CODEX_HOME. The prompt asked the model to ask one question.

Thread config	Question request (item/tool/requestUserInput)
Question feature forced on	1
Feature forced on + tools.experimental_request_user_input.enabled=false	0
The seat fragment	0
The seat fragment in Plan mode	0

The model also lists a request_user_input_async tool, but it never raised a request in any run, so the fragment covers what actually blocks.

Review focus

• The seat lookup in crewSeatRuntime.ts: whether "agent/MCP-created thread in a live Crew" is the right test, and that it fails open (no seat) when the store can't be read.

Closes #325

Claude Opus 5.5 via Claude Code in J5 Code

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Repository: Jacksondr5/j5code/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 9f6ed157-d3ba-403c-b45e-9713efb7217b

---

_{Comment @coderabbitai help to get the list of available commands.}