Inject (and refresh) the tools MCP into the session CLI's config + trust at spawn

[chaodu-agent]

Problem

When a Mac is lent to a session (reverse attach, #37 / §9 of CLIENT-CONTRACT), the runtime sets OPENAB_TOOLS_MCP_URL in the session child's environment — but the coding CLI does not read it. The human (or the agent) has to run, by hand, inside the session:

kiro-cli mcp add --name mac --url "$OPENAB_TOOLS_MCP_URL" --scope global

and, to avoid a y/N prompt on every tool call, also hand-write the agent's allowedTools (@mac/screenshot, @mac/browser_navigate, …). Two manual steps, per session, that most users will not know to do — and both hard-code the URL.

And the URL rotates. The <key> in the loopback URL is per session generation: a restart-in-place or a re-lend mints a new one, so every hand-written config (mcp.json and the agent's allowedTools server entry) goes stale and must be redone. Verified live 2026-09-26: after re-lending, the old key 404s.

Proposal

Have the runtime own the CLI's MCP wiring for the session, the way the Connect installer owns everything else about the workspace (this is the D-15 "the broker never edits agent config" rule's other side — openab-pty spawns the session, so it may):

• At spawn, if tools_listen is set, write/merge the mac server into the CLI's config for the detected agent CLI (~/.kiro/settings/mcp.json + the agent's allowedTools for kiro; the equivalent for other variants), with a sane default allowlist (the sandbox browser set + screenshot/mouse/key/osascript/sys_info/instance_status — never exec, which the sandbox does not have anyway).
• On generation change (restart-in-place) or when a grant is (re)installed, rewrite the URL so the config never points at a dead key.
• Keep it opt-in / per-variant: only variants whose config shape we know; unknown CLIs still get the env var and the manual path (§9.3).

Open questions:

• Where the per-CLI config shape lives — a small table in the runtime, or a hook the image provides. kiro is mcp.json + agents/<name>.json; codex/claude/others differ.
• Whether "trust" should be full allowlist or gated (an exec-style approval hop is a separate item; the sandbox profile already excludes the dangerous browser tools upstream, so a default-trust of the served set is defensible).
• Interaction with a running kiro-cli chat: MCP is loaded at start, so a session already in a chat needs a re-open. A notice into the PTY ("a Mac was lent; restart your agent to pick up its tools") may be the pragmatic bridge.

Acceptance

• Lend a Mac to a fresh session → open the agent → the Mac's tools are present and pre-trusted, with zero manual mcp add / config editing.
• Re-lend (new key) → the agent picks up the new URL without the human touching a file.
• A variant we don't know still works via the documented manual step; nothing regresses when tools_listen is unset.

Refs: §9.3 of runtime/CLIENT-CONTRACT.md; instance-mcp #10 (browser tools it exposes).

[chaodu-agent]

Platform-neutral alias decision (2026-09-28): auto-injection must register the server as computer, and trust @computer/*, not mac / @mac/*. Keep the URL contract unchanged: /mcp/{session}/{key}; /mcp/mac/... means the PTY session is named mac. Migration/documentation: #42.

[chaodu-agent]

Field finding (2026-09-29, kiro-1040 with three sessions: agent-black, agent-rp1, mac): each session was attached to a different computer, but sys_info from every session answered from macmini. The runtime env is correct per session (OPENAB_TOOLS_MCP_URL=…/mcp/<session>/<key>). The Kiro config is not: /workspace/.kiro/settings/mcp.json is one file shared by every session in the pod, and it was hard-coded to /mcp/mac/<key>.

Kiro does not expand ${OPENAB_TOOLS_MCP_URL} inside url. Tested: the server simply did not load. It does expand it inside env. What works today, verified from all three sessions (black / rpi1 / macmini each answered from its own computer): a stdio computer server that runs Kiro's bundled bun on a ~70-line bridge. The bridge forwards stdin JSON-RPC to $OPENAB_TOOLS_MCP_URL, handling the JSON/SSE response and echoing Mcp-Session-Id:

{"mcpServers":{"computer":{"command":"/workspace/.local/share/kiro-cli/bun","args":["/workspace/.local/share/computer-mcp-bridge.js"],"env":{"OPENAB_TOOLS_MCP_URL":"${OPENAB_TOOLS_MCP_URL}"}}}}

For this issue, that means auto-injection should write a session-independent config like this one, not a URL, whenever the workspace can be shared by several sessions.