[BUG] SECURITY: claude-in-chrome MCP controls browsers across different Claude accounts (extends #33813)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

This is an escalation of #33813, which was closed as stale without a fix. That issue demonstrated cross-device browser control within the same Claude account. This report documents the same behavior occurring across two different, unrelated Claude accounts — a significantly broader attack surface.

A Claude Code session authenticated to Account A controlled a Chrome browser on a separate physical machine where the Claude browser extension was signed into Account B. No shared account, no shared network requirement was verified as a prerequisite. The controlling session had no indication it was operating on a different machine.

Reproduction

1. Machine A (desktop PC): Windows 11, Claude Desktop App installed and signed into Claude Account A. Chrome is not running.
2. Machine B (laptop): Separate physical machine, Chrome running with the Claude browser extension active, signed into a different Claude Account B.
3. From a Claude Code session on Machine A, use any mcp__Claude_in_Chrome__* tool (e.g. screenshot, navigate, read page).
4. Observed: The tool connects to and controls Chrome on Machine B — a machine with a completely different Claude account.

Security Impact

This is more severe than #33813 because it does not require a shared account:

• Cross-account browser control: A Claude session can reach Chrome instances belonging to users on entirely different accounts
• No consent or notification on target machine: The user on Machine B receives no prompt, notification, or indicator that their browser is being controlled
• Full authenticated session access: Any page with active authentication (banking, email, corporate SSO, cloud consoles) is reachable and interactable from the controlling session
• Silent read operations: Read-only tools (screenshots, tab listing, page content, network requests) execute without any permission prompt, enabling silent data exfiltration

Root Cause (Observed)

The Claude-in-Chrome extension appears to connect to whichever Chrome instance with the extension installed is currently active and reachable via Anthropic's relay infrastructure, with no validation of account identity between the command source and the target extension. When Chrome is not running on the local machine but is running on another machine — even one with a different account — that remote instance is selected automatically.

What Was Investigated

cowork-svc.exe (a Windows service installed by Claude Desktop) was inspected and confirmed to be a local Hyper-V VM management service for Claude's code execution sandbox. It communicates only via a local named pipe, verifies client signatures, and is not involved in this issue.

The browser control path goes through chrome-native-host.exe and the Claude browser extension cloud relay. The isolation failure is in how commands are routed — there is no account-level gating between the command source and the target extension instance.

Expected Behavior

• Browser control tools should only reach Chrome instances authenticated to the same Claude account as the active session
• Cross-account browser control should be architecturally impossible
• Even within the same account, cross-device control should require explicit device pairing with consent on the target device
• All browser control actions (including read-only: screenshots, tab listing, page reads) should require an active permission prompt on the target machine

Environment

• Claude Desktop App v1.2773.0.0 (Windows 11 Pro, C:\Program Files\WindowsApps\Claude_1.2773.0.0_x64__pzs8sxrjxfjjc)
• Machine A: Windows 11 Pro, 3440×1440 display (Sceptre C35), Claude Account A
• Machine B: Separate physical laptop, Chrome running with Claude browser extension, Claude Account B
• Claude Code version: current (worktree session)

Related Issues

• #33813 — same behavior within a single account (closed as stale, not fixed)
• #25551 — connects to wrong browser when multiple Chrome instances on LAN (closed as stale)
• #37971 — read-only tools execute without permission prompt