Best possible solution:

Land one maintainer-approved shared-runtime implementation with session as the default, hashed/redacted shared runtime identity, explicit trusted single-tenant isolation docs, conflict-free exact-head validation, and a clear branch choice versus #95591.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level: current main and v2026.6.11 still key bundled MCP runtimes by session id, and the PR body provides repeated Docker terminal benchmarks showing the second matching session reuses the shared runtime in about 100 ms instead of paying another cold start. I did not run a live benchmark because this review is read-only.

Is this the best way to solve the issue?

No, not as-is. Workspace/config-keyed sharing is the right implementation layer for the fan-out problem, but this branch still needs a hashed shared runtime id, stronger primary config docs, conflict resolution, and maintainer acceptance of the new config/security boundary.

Full review comments:

• [P2] Hash the shared runtime key before surfacing it as a session id — src/agents/agent-bundle-mcp-runtime.ts:493-496
buildSharedRuntimeKey embeds the raw workspace path and full config fingerprint, and shared scope passes that key into the runtime as sessionId. Since session ids appear in errors/logging and diagnostic paths, this can expose local workspace identity and a stable config fingerprint; keep the raw tuple internal and use a hashed/redacted runtime id instead.
  Confidence: 0.87
• [P2] Document the shared-mode isolation tradeoff in config reference — docs/gateway/configuration-reference.md:179-184
  The primary configuration reference introduces "shared" but only says two sessions reuse one runtime. Add the trusted single-tenant warning here, including that MCP clients, child processes, catalog state, server-side state, and failure/backoff state can cross sessions, so operators see the boundary before enabling the config.
  Confidence: 0.85

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 9d68f877ac3e.

Label justifications:

• P2: This is a bounded opt-in MCP performance/resource-pressure feature with source-level evidence, but it touches config and runtime lifecycle boundaries.
• merge-risk: 🚨 compatibility: The PR adds mcp.runtimeScope and changes bundled MCP runtime ownership semantics for users who enable shared mode.
• merge-risk: 🚨 security-boundary: Shared mode intentionally lets MCP client, child-process, catalog, server-state, and failure-state behavior cross the current per-session runtime boundary.
• merge-risk: 🚨 availability: A shared MCP process, catalog load, hang, crash, stale TTL, or failure backoff can affect every attached matching session.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (terminal): The PR body includes repeated terminal benchmark output from a Docker-built branch image showing default session-scope cold starts and shared-scope reuse on the changed runtime path, plus a follow-up production ECS/Slack observation.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes repeated terminal benchmark output from a Docker-built branch image showing default session-scope cold starts and shared-scope reuse on the changed runtime path, plus a follow-up production ECS/Slack observation.

PR surface:

Source +176, Tests +344, Docs +13, Generated 0. Total +533 across 10 files.

Security concerns:

• [medium] Shared runtime id exposes workspace/config identity — src/agents/agent-bundle-mcp-runtime.ts:493
  The shared runtime key includes workspaceDir and configFingerprint and is passed as the runtime sessionId, which can surface through errors, logs, and diagnostics.
  Confidence: 0.87
• [medium] Shared MCP runtime crosses session isolation — src/agents/agent-bundle-mcp-runtime.ts:1137
  When mcp.runtimeScope is shared, matching sessions can attach to one MCP runtime and child-process set, so MCP client, catalog, server-side, and failure/backoff state can cross sessions for users who enable it.
  Confidence: 0.9

What I checked:

• Repository review policy applied: The root policy requires full AGENTS.md review, treats config additions and session/runtime boundaries as compatibility-sensitive, and requires whole decision-surface review for PR verdicts. (AGENTS.md:29, 9d68f877ac3e)
• Current main is still session-keyed: Current main stores bundled MCP runtimes in runtimesBySessionId, so matching workspace/config sessions do not share runtime ownership today. (src/agents/agent-bundle-mcp-runtime.ts:1002, 9d68f877ac3e)
• Runtime-local state would be shared: Each current runtime owns its own catalog, in-flight catalog promise, connected MCP sessions, and server failure backoff state; sharing the runtime also shares those states. (src/agents/agent-bundle-mcp-runtime.ts:507, 9d68f877ac3e)
• Embedded attempts use the session runtime: The hot path calls getOrCreateSessionMcpRuntime with the active session id and configuration before materializing bundled MCP tools. (src/agents/embedded-agent-runner/run/attempt.ts:1578, 9d68f877ac3e)
• Materialization blocks on catalog: Tool materialization acquires the runtime lease and awaits runtime.getCatalog(), which is the cold-start path the PR is trying to collapse for later matching sessions. (src/agents/agent-bundle-mcp-materialize.ts:392, 9d68f877ac3e)
• PR exposes raw shared key identity: The PR head builds the shared runtime key from raw workspaceDir and configFingerprint, then uses that key as the runtime session id in shared scope. (src/agents/agent-bundle-mcp-runtime.ts:493, 844f4e039262)

Likely related people:

• vincentkoc: CONTRIBUTING lists this person for Agents, and live PR history shows they merged recent MCP runtime/fingerprint work that this PR must preserve. (role: listed Agents maintainer and recent merger; confidence: high; commits: a2725b6a24c8, 26f92a4f8d5f; files: src/agents/agent-bundle-mcp-runtime.ts)
• mmyzwl: Authored the merged catalog-parallelization PR touching the same bundled MCP runtime manager and catalog path. (role: recent runtime contributor; confidence: high; commits: a2725b6a24c8; files: src/agents/agent-bundle-mcp-runtime.ts)
• openperf: Authored the merged MCP lease-release idle-eviction fix whose active-lease and TTL invariants are directly affected by shared runtime ownership. (role: recent lifecycle contributor; confidence: high; commits: f2530de8320e; files: src/agents/agent-bundle-mcp-runtime.ts, src/agents/agent-bundle-mcp-runtime.test.ts)
• steipete: Recent MCP operability/config/docs commits shaped the runtime and documentation surface this PR extends. (role: feature-history contributor; confidence: medium; commits: 99ce71ddbbdb, 38d3d11cbc0c; files: src/agents/agent-bundle-mcp-runtime.ts, src/config/types.mcp.ts, docs/gateway/configuration-reference.md)
• YonganZhang: Authored the merged SHA-256 config fingerprinting change adjacent to the PR's workspace/config-fingerprint shared key behavior. (role: recent adjacent contributor; confidence: medium; commits: 26f92a4f8d5f; files: src/agents/agent-bundle-mcp-runtime.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.