Multi-agent browser automation: safe Chrome tab control
2026-07-27
AI agents are useful in a real, logged-in browser only when they can stay in the tab they are meant to control. That becomes especially important when more than one agent, or a person and an agent, are using Chrome at the same time.
Before this update, thinkrun --tab <id> could fail even when the tab belonged to the same local session. The command omitted the session identity that the local browser bridge uses to recognize its owner. That made a safe workflow unnecessarily awkward: open an isolated window, then address it by its tab id without being affected by whatever tab a person was currently viewing.
Why multi-agent browser automation needs tab ownership
Local browser automation gives an AI agent access to the browser state a fresh headless profile cannot see: an existing login, an in-progress workflow, and the rendered page a person is actually using. It should not give that agent a license to take over every open tab.
ThinkRun treats the browser's native host as the authority for tab ownership. An agent can continue in the isolated window it opened, but another local agent's tab remains off limits. That separation is what makes a local browser MCP or CLI workflow usable alongside a person's normal browser work.
What changed in ThinkRun
For a --tab <id> command, ThinkRun now forwards the active session identity only when the selected tab is locally confirmed as self-owned and it matches that session's current tab binding. That lets an agent continue working in the isolated window it opened.
The behavior remains deliberately narrow:
- Unowned tabs are still accessed anonymously, preserving the existing local workflow for those tabs.
- A tab locked by another local agent is still rejected before the command reaches the browser.
- The browser's native host remains the authoritative ownership check.
So this is not a broader permission change. It fixes identity forwarding for the session that already owns the target tab, while keeping cross-agent isolation intact.
Safely control the right Chrome tab
For a local browser automation task, start by opening an isolated window rather than attaching to a tab another workflow may already own:
TAB_ID="$(thinkrun new-window https://example.com --json | jq -r '.data.tabId')"
thinkrun evaluate --tab "$TAB_ID" 'document.title'
thinkrun session debug --json
The first command opens and attaches to a local Chrome window, then reads its data.tabId from the JSON response. The second explicitly targets that tab, carrying the identity of the session that owns it. The third reports active local continuity and ownership state, so an agent can distinguish its own session from a stale binding or a genuine foreign-owner block before it retries work.
When a command explicitly targets the tab the current session owns, ThinkRun carries that session identity. If another agent tries to target that tab, the browser's ownership check still blocks it. When the work is finished, release the local session so the ownership state is unambiguous:
thinkrun release --json
See the ThinkRun CLI and local-mode documentation for setup, recovery guidance, and the complete command reference.
Local browser MCP and CLI workflows
This release changes the local CLI tab-targeting path. It does not change MCP behavior: the MCP local client already uses its own explicit tab and session identity mechanism. The useful principle is the same for either integration: an agent should act only in the browser context it has been given, and ownership checks should remain authoritative.
That matters whether you are asking Claude Code, Codex, or another coding agent to verify a UI, continue a logged-in workflow, or inspect a problem in a real browser. Local browser control is most helpful when it is precise about which tab the agent may use.
If you are deciding between live browser tools more broadly, read our Playwright MCP alternatives guide. It explains when live browser control is the right tool and when a recorded browser session is more useful evidence.