feat(server): Pi 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
3. feat(server): Pi Captains propose a Crew without a native prompt #303: Pi Captains propose a Crew without a native prompt ⬅️ this PR
4. feat(server): ACP Captains propose a Crew without a native prompt #304: ACP Captains propose a Crew without a native prompt

Problem

A Pi Captain got Pi's own confirm before the roster gate in every mode short of full access (#266). T3's injected Pi extension asks before every non-read tool, and Pi only receives the runtime mode, so a saved persona whose policy is never still got prompted for every J5 call.

What I changed

• apps/server/src/j5/a2a/mcp/piToolApproval.ts (new):
  • j5PiPreapprovalEnv puts T3_J5_PREAPPROVED_TOOLS (the comma-joined mcp__t3-code__<tool> names from j5PreapprovedTools(policy), computed on the server) and T3_J5_PI_EXTENSION_PATH into the launch environment.
  • J5_PI_PREAPPROVAL_SOURCE is the extension preamble that defines j5Preapproved(toolName).
• PiAdapterV2.ts spreads the env into the launch; piT3McpExtensionSource.ts interpolates the preamble and consults j5Preapproved in the tool_call hook. Both are upstream files, recorded as FORK.md case 47.
• docs/user/personas.md: Pi moves to the harnesses that never add a step.
• The preamble has no import or await: it normalizes paths through process.getBuiltinModule("node:path") and compares exactly where that's unavailable. The first push used await import("node:path"), which broke the upstream piT3McpExtensionSource.test.ts VM harness in CI; 88673084ee fixes it.

Why this shape

Pi leaves permission policy to extensions, so the extension is the only place to skip a confirm. The server computes the list because only it can tell a persona's never policy apart from plain approval-required.

Invariants

• A listed name alone proves nothing, because Pi extensions can register tools under any name. The confirm is skipped only when:
  • the name carries the mcp__t3-code__ prefix;
  • it is in the env list;
  • pi.getAllTools() resolves it to the same parameters object this extension registered;
  • its sourceInfo.path is the bridge's own --extension path.
• Anything it can't verify, including a Pi without getAllTools, is still confirmed.
• Both env keys are always set (empty without T3 MCP credentials), so a value inherited from a parent process can never widen a session.

Surfaces

Surface	Decision
Entry points (chat, Settings, command palette, keybinding)	Unaffected.
Clients (web, desktop, mobile)	Unaffected.
Providers	Pi only.
Contracts (packages/contracts)	Unchanged.
Reverse states	n/a.
Connection modes (local, remote, tunnel)	Unaffected.
Upstream files / FORK.md	PiAdapterV2.ts and piT3McpExtensionSource.ts, recorded as FORK.md case 47.
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.
  None beyond the stack's blocked issues (Capture and match Grok MCP permission requests #268–Cursor Captains need Full access until the Cursor SDK exposes MCP approval #270).

Upgrade and data

None.

Verification

• piToolApproval.test.ts runs the extension's tool_call hook in the VM harness. It checks the confirm is skipped exactly for the shared set per mode, other tools are still asked, a non-t3-code name injected into the env is ignored, a same-named tool from another extension is asked, and env parity holds over the policy matrix.
• PiAdapterV2.test.ts and the upstream piT3McpExtensionSource.test.ts passing; locally the whole orchestration-v2/Adapters directory, the mcp dir, and provider/acp pass (864 tests).

Review focus

• The identity check in J5_PI_PREAPPROVAL_SOURCE (same parameters object plus the resolved sourceInfo.path): is there a Pi API that lets another extension replace a registered tool's entry while keeping that object?

Closes #266

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: 511b5bf9-39ac-452f-bbf0-73fde8f702dc

---

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

[Jacksondr5]

[Review panel: Opus 5.5 + Astra + Fable 5.1] FORK.md case 47 doesn't match the code.

• It quotes j5PiPreapprovalEnv(input.runtimePolicy, mcpSession !== undefined), but the adapter passes three arguments, including extensionPath.
• It never mentions the second env key (T3_J5_PI_EXTENSION_PATH) or the sourceInfo.path check. The case describes the identity check as the parameters object alone.

A rebase that follows case 47 would get the wrong call site. Fix: update the call and list both env keys. If you take the simplification I suggest on piToolApproval.ts, both of these go away.

[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. Pi needs a change inside upstream's injected extension, which is hard and adds fork surface for a harness we don't use. 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 Pi 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 #266 as not planned for the same reason.