feat(server): OpenCode Captains propose a Crew without a native prompt

[bryantderosier]

Important

⚠️ Merge order: merge these in this exact order

This PR is part of the Captains stack. Merge top to bottom, one at a time; each PR is based on the one above it. The stack has no migrations and no ordering against the other Crews PRs.

1. refactor(server): one J5 tool pre-approval list for Codex and Claude #301: One J5 tool pre-approval list, and every adapter can be a Captain
2. feat(server): OpenCode Captains propose a Crew without a native prompt #302: OpenCode Captains propose a Crew without a native prompt ⬅️ this PR
3. feat(server): Pi Captains propose a Crew without a native prompt #303: Pi Captains propose a Crew without a native prompt
4. feat(server): ACP Captains propose a Crew without a native prompt #304: ACP Captains propose a Crew without a native prompt

Problem

An OpenCode Captain couldn't propose a Crew without an extra step (#265). OpenCode checks each MCP tool as its own permission (<server>_<tool>), and the adapter's policy seeds * deny then * ask. So propose_crew raised a native OpenCode prompt in interactive modes, and a read-only persona's policy hid it entirely.

What I changed

• apps/server/src/j5/a2a/mcp/openCodeToolApproval.ts (new): j5OpenCodeAllowsT3McpTools decides whether the allows are safe for this session; j5OpenCodePermissionRules builds one t3-code_<tool> allow per name in j5PreapprovedTools(policy).
• OpenCodeAdapterV2.ts (upstream, FORK.md case 46):
  • openCodePermissionRules pushes the J5 rules as its last statement.
  • One j5OpenCodeAllowsT3McpTools(client, hasT3Mcp) check runs after mcp.add.
  • The flag is passed at all three permission sites (child session.update, both session.create), defaulting to false.
• docs/user/personas.md: OpenCode moves to the harnesses that never add a step; an external OpenCode server still can't propose.

Why this shape

OpenCode's rules match last-wins, so appending allows at the end is the one place they take effect without rewriting upstream's policy. I rejected a wildcard t3-code_* allow: that would also wave through worktree handoff, preview, and scheduling.

Invariants

• Fails closed: allows are installed only when T3 injected its own t3-code server (never on an external OpenCode), mcp.status reports it connected, and no other server's sanitized name starts with t3-code_. A server named t3-code_send with a tool message would also produce t3-code_send_message, and the check blocks that. A status error means no allows.
• The push stays the last statement before return rules;, and full access still returns its early * allow without reaching it.
• Child task sessions get the parent's full rules followed by their own, so a child's verdict for every t3-code tool matches its parent's (tested).

Surfaces

Surface	Decision
Entry points (chat, Settings, command palette, keybinding)	Unaffected.
Clients (web, desktop, mobile)	Unaffected.
Providers	OpenCode only.
Contracts (packages/contracts)	Unchanged.
Reverse states	n/a.
Connection modes (local, remote, tunnel)	Unaffected. An external OpenCode server gets no allows, by design.
Upstream files / FORK.md	OpenCodeAdapterV2.ts, recorded as FORK.md case 46.
Docs	docs/user/personas.md.

Out of scope

• FORK.md numbering follows landing order: the formatter keeps the case list consecutive, so the Captains stack (feat(server): OpenCode Captains propose a Crew without a native prompt #302–feat(server): ACP Captains propose a Crew without a native prompt #304) and feat(crews): answer a Crew thread's provider approvals and questions from the Inbox #309 both start at case 46 on their branches. Whichever lands second renumbers its cases and file-table rows when it's brought up to date with j5/main.
• A server added to the running OpenCode after the session starts isn't seen by the check. I accept that because T3 spawns and owns that process (noted in case 44).

Upgrade and data

None.

Verification

• openCodeToolApproval.test.ts: over the shared policy matrix, the effective last-matching rule is allow exactly for the shared set; handoff, preview, and scheduling keep OpenCode's verdict; child sessions match the parent; the collision check and the fail-closed status paths are covered.
• OpenCodeAdapterV2.test.ts unchanged and passing.

Review focus

• j5OpenCodeT3McpKeysAreOurs: is OpenCode's sanitizer ([^a-zA-Z0-9_-] → _) the only way two server names can produce the same key prefix?

Closes #265

Claude Opus 5.5 via Claude 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: 557cf69e-e742-4ab3-ab79-fd2def66e797

---

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

[Jacksondr5]

Closing (Jackson, 2026-09-26). Per the ruling on #233, J5 pre-approves its tools only on Codex and Claude. Other harnesses may show their own MCP prompt once before the roster card, which is acceptable. OpenCode would be simple, but there aren't enough users to justify the extra fork surface in an upstream adapter. A general fix for T3's own MCP tools belongs upstream and is tracked in #276. Thanks for the careful work here: the review surfaced real upstream gaps, which are now recorded.

[Jacksondr5]

Reopened: closing it was my overreach, not Jackson's call. The decision above stands (per #233, J5 won't pre-approve its tools on this harness), so it won't merge. @bryantderosier, closing it is yours to do whenever you like.

[bryantderosier]

@Jacksondr5 Closing this per your ruling on #233: J5 pre-approves its tools only on Codex and Claude, and a OpenCode Captain may show its own MCP prompt once before the roster card. The general fix for T3's own MCP tools is tracked upstream in #276. Thanks for the panel's review; the gaps it found are recorded there. I'm closing #265 as not planned for the same reason.