feat(desktop): agent browser bridge — MCP server driving webtab guests via CDP (WebBridge model, MCP-native)

[agentfleets]

Proposal

Give agents (kimi-code first; any MCP engine) controlled access to the desktop's embedded browser (<webview> webtabs) via a browser-bridge MCP server in the Electron main process, backed by webContents.debugger CDP. This is Kimi WebBridge's architecture (local service + CDP) rebuilt MCP-native and scoped to TermiPod.

Grounding (verified on this Mac, kimi-code 0.28.1 + current main)

• WebBridge itself is not reusable: in the 0.28.1 binary it is only a pinned marketplace promo (kimi-webbridge, application/x-google-chrome-extension, "open in browser" → features page). The kimi-code CLI has no WebBridge client; the driver is Kimi Work (closed protocol). Feature page: local service + Chrome extension, agent commands → CDP.
• No extension needed here: webtabs are Electron <webview> guests (electron/src/webtab.ts, partitions in webtab_policy.ts); the main process can attach webContents.debugger and speak raw CDP in-process. Verified live: TermiPod with --remote-debugging-port=9333 answers /json with Chrome 150 / protocol 1.3.
• The tool-delivery channel exists today: hostrunner writeMCPConfigForFamily (launch_m2.go:676) injects per-spawn MCP config per family (kimi → <workdir>/.kimi-code/mcp.json, auto-discovered; claude → .mcp.json; codex/gemini equivalents). A bridge server entry is additive.
• Precedent tools: Google's chrome-devtools-mcp (--browserUrl) and @playwright/mcp (--cdp-endpoint) validate the tool-surface shape (snapshot/click/type/navigate/screenshot over CDP + accessibility tree). A zero-code spike (launch TermiPod with --remote-debugging-port, point stock MCP at it) works but exposes the app:// shell too — not shippable.

Shape (details in the plan doc, PR to follow)

• W1 read-only: loopback+bearer MCP in main; browser_list_tabs / browser_snapshot (AX tree) / browser_screenshot / browser_read_text; scoped strictly to allowlisted guest partitions (never the shell); desktop toggle (default off); discovery file ~/.termipod/browser-bridge.json (0o600, per-run token); hostrunner injects the stdio bridge entry at spawn.
• W2 actions: navigate/click/type/scroll/eval behind per-spawn opt-in; partition navigation policies enforced on tool calls (kimiweb stays loopback-pinned); audit events into the hub transcript.
• W3 hub-relayed: remote hosts drive the desktop browser through the hub WS; approval routing for action calls.

Security headline: webtab partitions persist real login cookies → web content is a prompt-injection vector; read vs action tool classes with separate gates.

[agentfleets]

Claimed by @agentfleets — plan doc PR first (per request), implementation wedges after maintainer review. ETA: doc today.

[agentfleets]

W1 implementation starting (branch agent/agentfleet/455-browser-bridge-w1): read-only bridge per the accepted plan — browserbridge.ts (HTTP MCP + registry + debugger sessions, four read tools), desktop toggle, discovery file, hostrunner injection for all four families (read scope), browser_bridge_stdio.mjs, unit + e2e tests. W2/W3 stay as follow-ups.

[agentfleets]

W1 implemented in #471 — read-only bridge (four read tools), desktop toggle, discovery file, hostrunner injection for all four families, stdio relay, unit + e2e coverage. W2/W3 remain per the plan.

[agentfleets]

W2 implemented in #472 — the action tool set (browser_navigate/browser_find_tab/browser_click/browser_type/browser_send_keys/browser_scroll/browser_upload_file/browser_eval) behind the per-spawn opt-in (browser_bridge: true → the discovery file's action token), partition-policy enforcement on navigate + PARTITION_READ_ONLY on kimiweb/rerunweb, and the audit trail (last-50 ring in Settings → Assistant + best-effort hub agent_events mirror, typed text redacted, agent attributed via x-tp-agent-id). Unit (29 core + hostrunner scope matrix) and Playwright e2e coverage included. W3 (hub relay) remains per the plan.