4.3.0: MCP server fails to start over Bridge host ("unavailable"); 4.2.2 CLI works against same 4.3.0 bridge

[smhanov]

Regression: 4.3.0 MCP-over-Bridge broken

CLI 4.3.0 (main/44eff916c) + Peekaboo.app 4.3.0 (4030099), macOS 27.0 arm64.

peekaboo mcp (default serve) fails immediately:

[DEBUG] Runtime host: remote gui via .../bridge.sock (build 4.3.0 (4030099))
[DEBUG] MCP: using remote Bridge host; skipping local daemon startup
[ERROR] Failed to start MCP server: unavailable

Same with mcp serve and mcp serve --allow-foreground; persists after daemon stop.

What still works

• peekaboo mcp --no-remote starts fine (but caller-local has no Screen Recording/AX, so captures/actions fail there).
• 4.2.2 CLI's mcp starts fine against the same 4.3.0 bridge (initialize OK, tools/list OK) — so the bridge is healthy (bridge status handshake OK). But 4.2.2-issued captures then fail receipt validation on the 4.3.0 bridge (see --app Terminal → INTERNAL_SWIFT_ERROR / MCP see → Bridge operation receipt does not match operation facts).
• Pixel-only paths work on both versions (see --mode screen --no-elements).

Possibly related

Full-screen AX observation (see --mode screen with elements) fails on both 4.2.2 and 4.3.0 (desktop observation provider ... unexpected application evidence / INTERACTION_FAILED), though the screenshot file is still written. App-targeted see works on matched versions.

Impact

Opencode MCP clients that rely on bridge-backed screenshots/actions cannot use 4.3.0 at all; matched 4.2.2 set is the last working combo. Happy to provide verbose/trace logs.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 16, 2026, 4:42 PM ET / 20:42 UTC.

Summary
The reported GUI Bridge startup failure remains source-reproducible on current main, and v4.4.0 retains the same mechanism. Browser-session isolation is intentional, but its startup requirement also blocks native screenshot and automation tools.

Reproducibility: yes. from source: select a GUI Bridge host with the default MCP catalog, which includes browser; the absent scoped transport causes unavailable during server initialization. This review did not execute a macOS reproduction.

Regression provenance
Possible regression — suspected (failure trace). No predecessor PR is attributed.

Maintainer decision needed

Question	Recommendation
Should GUI-backed MCP automatically omit unsupported browser tools, or continue requiring an explicit browser-free catalog?	Start with supported native tools: Omit unsupported browser tools with a clear diagnostic while retaining strict failures for explicit browser handoffs.

Why: Existing tests and merged design explicitly require unsupported browser sessions to fail closed; choosing graceful native-tool startup changes the default catalog contract.

Next step
Choose the GUI-backed catalog behavior before dispatching a repair; meanwhile, the documented browser-free catalog is a mitigation, and shared-root fallback must remain prohibited.

Review details

Best possible solution:

Allow native MCP tools to start on GUI Bridge hosts through capability-aware catalog selection, clearly explain unavailable browser support, and preserve strict isolation and explicit handoff validation.

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

Yes, from source: select a GUI Bridge host with the default MCP catalog, which includes browser; the absent scoped transport causes unavailable during server initialization. This review did not execute a macOS reproduction.

Is this the best way to solve the issue?

Unclear until the default catalog policy is chosen; existing browser filtering offers a bounded mitigation, while bypassing session checks or borrowing the Bridge root would contradict the approved isolation contract.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Automatically removing browser from a GUI-backed catalog changes tool availability; enabling GUI browser sessions instead would require preserving authenticated caller isolation.
• The mixed-version receipt failures and full-screen accessibility observation errors are not established as the same root cause and remain unverified.

Codex review notes: model internal, reasoning medium; reviewed against 4d3c92eaf6e0.

Label changes

Label changes:

• add P1: A concrete reported regression blocks Bridge-backed MCP screenshots and actions, and the failure mechanism remains on current main.
• add impact:other: MCP server startup fails before external automation clients can use native desktop tools.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P1: A concrete reported regression blocks Bridge-backed MCP screenshots and actions, and the failure mechanism remains on current main.
• impact:other: MCP server startup fails before external automation clients can use native desktop tools.

Evidence reviewed

What I checked:

• Concrete reported failure: The reporter supplies CLI 4.3.0, app build 4030099, macOS 27 arm64, and a startup trace selecting a remote GUI host before failing with unavailable. Local MCP starts, and the older CLI initializes against the same Bridge. No additional human discussion was present in the supplied context.
• GUI hosts receive no scoped browser transport: supportsBrowserConnectionHandoff requires hostKind == .onDemand. RuntimeHostResolver.swift:979 uses this predicate to supply the browser session transport or nil, so a GUI host cannot receive it through this path. (Apps/CLI/Sources/PeekabooCLI/Commands/Base/Runtime/BridgeCapabilityPolicy.swift:686, 4d3c92eaf6e0)
• Default catalog makes browser bootstrap a startup dependency: prepareToolContext opens a browser session whenever the selected catalog includes browser. MCPToolCatalog includes BrowserTool, and background policy excludes shell, drag, and move rather than browser. RemoteBrowserMCPClient.swift:89 throws unavailable when its session transport is nil. (Core/PeekabooCore/Sources/PeekabooAgentRuntime/MCP/Server/PeekabooMCPServer.swift:126, 4d3c92eaf6e0)
• Tests preserve the restriction and filtered recovery path: BrowserSessionTransportRuntimeTests explicitly expects GUI hosts to lack scoped transport. RemoteBrowserMCPSessionTests verifies browser-free catalogs can initialize against an unscoped remote provider, browser catalogs fail closed, and explicit handoffs still bootstrap even when browser is filtered out. These tests were inspected, not executed. (Apps/CLI/Tests/CoreCLITests/BrowserSessionTransportRuntimeTests.swift:23, 4d3c92eaf6e0)
• Existing documented mitigation: The MCP documentation states that filtering browser out avoids browser bootstrap and permits browser-free catalogs on legacy remote providers. This mitigates the startup dependency but does not restore the reported default invocation. (docs/commands/mcp.md:57, 4d3c92eaf6e0)
• Maintainer-approved isolation contract: The merged fix(browser): isolate caller capability sessions #646 explicitly adopts fail-closed browser isolation and rejects shared-root fallback. Its author is steipete; local feature history also identifies Peter Steinberger on the browser client and MCP startup paths. This establishes relevant ownership and design context, not verified causal attribution for this report. (b75aa57513c7)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• 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.