Claude's Browser Extension Is A Hidden Channel Between Your Devices By Aner Morag
Two devices logged into the same Anthropic account share a WebSocket bridge with no device-level isolation. Anthropic confirmed the design is intended. Here is what it means for any organization where employees use the same Claude account on personal and corporate machines.
The Claude Browser Extension can navigate pages, read their full content, execute JavaScript, fill forms, and interact with every tab you have open. It holds <all_urls>, scripting, debugger, and tabs permissions and injects a content script into every page, in every frame, at document load. This level of access is necessary for what the extension does. It is also the kind of access that security teams spend considerable effort controlling.
We discovered that when you use the same Anthropic account on two devices — say a corporate laptop and a personal machine — the extension on both devices joins the same communication channel. Commands issued on one device can silently execute on the other. The full content of whatever page the other device is viewing flows back to the requesting session, with no prompt or indication to either user.
We reported this to Anthropic. They confirmed this is intended behavior. The cross-device execution and the choice not to enforce device ID validation are by design.
This is not a theoretical attack. It happened during an internal research session unintentionally, when a browser command meant for one laptop executed on an engineer’s machine in the next room.
How It Works
The extension communicates through a WebSocket bridge at bridge.claudeusercontent.com, keyed by the Anthropic account UUID, not the device. Every Chrome instance running the extension on the same account connects to the same room.
wss://bridge.claudeusercontent.com/chrome/{account-uuid}When Claude Code or Claude Desktop issues a browser command, it travels through Anthropic’s cloud to the bridge, which forwards it to the connected extension. Each tool call includes a target_device_id field for routing. The entire device validation in the extension source is two lines:
const t = e.target_device_id; if (t && t !== Ia) return;
If target_device_id is present and does not match, the message gets dropped. If it is missing, the command executes on every connected device.
The device ID itself is a crypto.randomUUID() stored in chrome.storage.local. It is not cryptographically bound to hardware. It is not validated server-side.
The Cross-Device Channel
We set up two Chrome instances on the same Anthropic account. Machine A was our test environment (tab IDs in the 710137xxx range, viewport 1280×806). Machine B was a separate browser.
We sent a command from Claude Code on Machine A: get the browser tab context. The response came back with tab ID 1138155643 and viewport 1040×584. That was Machine B’s browser. Claude Code accepted the response and continued without any indication something was wrong.
We also intercepted the native messaging pipes between Chrome and the native host binary. The local channel carried only four messages per session: ping, pong, get_status, status_response. A health check, nothing else. Every tool call goes through the cloud bridge exclusively. There is no local path.
Why This Matters
The issue is not account authentication. OAuth tokens are fine for that. The issue is what happens after. The extension’s broad browser privileges are shared across every device on the account through a cloud channel with no device-level isolation.
Consider a common setup. A developer uses the same Anthropic account on their work laptop and their personal machine.
The work laptop. Behind a corporate VPN, managed by MDM, monitored by endpoint security, subject to DLP policies. Access to internal dashboards, cloud consoles, HR systems, financial reporting, customer data.
The personal machine. On home WiFi. Maybe has not been updated in months. Maybe has an infostealer running quietly from something downloaded last quarter. No corporate visibility. No DLP. No managed posture.
The shared channel. Both devices, the same Anthropic account, the same WebSocket bridge room. Commands issued on one device can execute on the other with no prompt and no indication.
When a command from the work laptop gets routed to the personal machine, corporate data crosses every one of those boundaries. The internal dashboard’s content travels from the corporate network, through Anthropic’s cloud, to the personal machine, and back. The company’s network controls never see it. The request originated from home WiFi. The company’s DLP never catches it. The data moved through a WebSocket to a legitimate cloud service.
Nobody did anything wrong. The user just had two computers with the same account.
If the personal machine is compromised, an attacker with access to the OAuth token (stored in Chrome’s extension storage) can sit in the bridge room and receive the content of everything the corporate browser reads.
What The Extension Sees
When Claude reads a page, it extracts the full accessibility tree: every heading, link, form field with its current values, button, and text content. The output of a single tool call against a revenue dashboard looks like this:
{
"type": "tool_result",
"content": [{
"type": "text",
"text": "heading \"Q4 Revenue Dashboard\" [ref_1]
generic \"Total Revenue: $14.2M (+12% YoY)\" [ref_2]
table [ref_3]
row \"Enterprise\" \"$8.1M\" \"57%\"
row \"Mid-Market\" \"$4.3M\" \"30%\"
link \"Export to CSV\" [ref_4]
textbox \"Filter by region\" [ref_5] value=\"EMEA\"
button \"Generate Report\" [ref_6]"
}]
}Every response also includes a Tab Context listing all open tabs and their URLs, sent with every response, even when the agent is only interacting with one tab:
Tab Context: - Available tabs: - tabId 710138082: "Internal Dashboard" (https://admin.corp.example/) - tabId 710138083: "Gmail - Inbox" (https://mail.google.com/...) - tabId 710138084: "Salary Review Q4" (https://hr.corp.example/reviews)
The extension injects accessibility-tree.js into every page you visit, in all frames, at document_start. The infrastructure to extract page content is always present, whether or not the agent is actively reading that tab.
The Permission Mode On The Wire
Every tool call includes the active permission mode:
{
"type": "tool_call",
"tool": "navigate",
"permission_mode": "skip_all_permission_checks"
}The extension trusts whatever permission mode it receives. There is no server-side enforcement.
Closing The Gap At The Agent Layer
Anthropic considers the cross-device channel intended behavior. The responsibility for controlling it falls on the organizations whose data it can carry. The bridge is invisible to traditional endpoint security. To a firewall or DLP, it looks like normal HTTPS traffic to a legitimate cloud service. The control point has to be at the agent layer, not the network layer.
A new class of agent-security tooling has emerged to address this layer. Bay, the platform that conducted this research, is one example. These tools operate by inventorying which AI agents and browser extensions are running on every endpoint, evaluating each agent action against organizational policy before it executes, and applying allow, ask, or deny decisions across every device in the organization. When an agent issues a browser command (navigate to a URL, read a page, execute a script), the decision happens before the command runs.
The bridge is invisible to traditional endpoint security.
For the scenario in this research, that means the cross-device channel becomes visible and controllable. The work laptop’s command does not silently execute on the personal machine. The page content from the personal machine does not silently flow back to the requesting session. The policy decision happens at the agent layer, where the action originates.
The cross-device channel will not be the last design decision in agentic AI tooling that creates this kind of architectural mismatch with traditional enterprise security. Organizations that build the agent-layer visibility and control now will be ready for the next one. Organizations that wait for the vendors to add the controls will keep finding out about them the way this one was found — when a command meant for one machine quietly executes on another in a different room.
What To Put In Place
Inventory AI agents on every endpoint. Know which AI tools and browser extensions are running on every managed device, what permissions they hold, and what actions they are authorized to take. The Claude browser extension is one example. There are now dozens of AI browser extensions and desktop agents with comparable access.
Evaluate agent actions against policy before execution. When an agent issues a browser command (navigate to a URL, read a page, execute a script) the action should be evaluated against organizational policy before it executes. The decision should be allow, ask, or deny, applied automatically across every device in the organization.
Make cross-device channels visible. WebSocket bridges and cloud-routed agent commands do not appear in traditional endpoint security. Visibility into the agent layer — which agent took which action against which page on which device — is what closes the gap. Network and endpoint controls alone cannot.
Treat shared accounts as shared attack surfaces. Until vendors enforce device-level isolation in agent extensions, the same account on two machines means a shared bridge room. Account-level access is no longer a sufficient boundary when the resulting privilege spans devices with different security postures.
About The Author
Aner Morag is the co-founder and CTO at Bay, an agent-layer security platform. The research described in this article was conducted as part of Bay’s work on AI agent visibility and control. Anthropic was notified of the findings and confirmed the cross-device behavior as intended.