Sign up
View stargazersSign up

feat(cua): let agents use your signed-in browser tabs on any host#16532

draft1
t3code/cua/5-pip
t3code/cua/6-browser-tabs
opened23d agobyJJulius Marminge
29 files changed
View on GitHubTwo-way sync enabledPR last imported 12h ago

Agent browser tabs lets agents work in the Chromium browser the user already has open, with their tabs and sign-ins, through Chrome DevTools MCP. This was half of #15006, which only supported macOS.

  • Detects Chrome, Edge, Brave, Helium, and Chromium profiles on macOS (~/Library/Application Support), Linux ($XDG_CONFIG_HOME), and Windows (%LOCALAPPDATA%). The browser with remote debugging on is used first.
  • Status checks never open the debugging port, since a connection is what asks the user to allow access.
  • Setup lists the browsers, copies each one's remote-debugging page, and installs the pinned Chrome DevTools MCP 1.10.1 on Done.
  • Every provider attaches it beside cua-driver, including OpenCode 2 (per thread) and Pi (through the same extension bridge), with a <browser_tabs> prompt block.
  • Restore defaults lists and resets Agent browser tabs.

Verification

  • Focused tests: profile detection on all three OS layouts, runtime instructions, Pi extension.
  • Not yet verified with a real browser connection.

Built with Claude Opus 5.5 in T3 Code, through the Claude Code harness.

🤖 Generated with Claude Code

Checks

21 successful · 7 skipped
All checks passed
a7e8afd
Ggithub-actionsBot23d ago
Synced from GitHub

Thread transfer impact

âś… Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

ProviderMetricMain baselineThis PRImpactPR ceiling
CodexTotal thread wire—5.0 KiB—6.8 KiB✅
CodexThread snapshot wire—3.8 KiB—4.9 KiB✅
CodexLive turn WebSocket wire—1.2 KiB—2.0 KiB✅
CodexLive turn WebSocket decoded—21.6 KiB—24.4 KiB✅
CodexLive turn messages—2—8✅
ClaudeTotal thread wire—5.0 KiB—6.8 KiB✅
ClaudeThread snapshot wire—3.8 KiB—4.9 KiB✅
ClaudeLive turn WebSocket wire—1.3 KiB—2.0 KiB✅
ClaudeLive turn WebSocket decoded—21.9 KiB—24.4 KiB✅
ClaudeLive turn messages—2—8✅

Baseline: unavailable · PR result: a7e8afd · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

  • Codex decoded thread snapshot: 108.5 KiB
  • Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

Ssprintthunder-dotcom21d ago
Synced from GitHub

Sharing a real-world use case in case it helps scope this.

My setup: the main thread runs Opus 5.5 and delegates work to sub-agents on GPT Sol 6.1. On Windows with Edge, I sign in to a work web app in the built-in browser from the main thread. But when a worker sub-agent then opens the same app, it doesn't inherit that signed-in session, so it lands on the Microsoft account picker / MFA again and has to log in a second time.

It would be great if sub-agents could reuse the session (or the signed-in browser profile/tab) that the parent agent already authenticated, so one login covers the whole orchestration. Happy to test on Windows + Edge.

Hhillimited18d ago
Synced from GitHub

Same need here (+1), from the human→agent direction. My workflow is attended login: I open a tab in the T3 browser and sign in, expecting the agent to then browse that signed-in session — but the agent can't touch human-opened tabs ("belongs to another agent session or a human") and its own tabs start with blank storage, so the login is wasted and the agent burns turns probing the human tab before falling back. One login covering the orchestration is exactly what's missing. Happy to test.

Ssaphid7d ago
Synced from GitHub

Source review of 509d3bf: server.runBrowserTabsAction is guarded by AuthOrchestrationOperateScope on the server, but is absent from CLIENT_GUARDED_RPC_SCOPES. BrowserTabsSetting also does not use the command’s permissionAtom to gate Setup/Done. A connected person with settings-write but no orchestration-operate grant can therefore be offered an install action that the server will reject.

Please add the client permission mapping, use the command’s permission availability for setup/install, and extend the focused permission behavior test. Keep the server check. The relevant paths are packages/contracts/src/clientRpcPermissions.ts, packages/client-runtime/src/state/server.ts, and apps/web/src/components/settings/IntegrationsSettings.tsx.

This is a source-derived finding; I have not reproduced the restricted-scope flow or a real host-browser connection. It does not claim an authorization bypass.

Added 1 commit

  • feat(cua): let agents use your signed-in browser tabs on any hosta7e8afd