Chrome extension remote control

Resolved 💬 3 comments Opened Apr 22, 2026 by Qonye Closed Apr 25, 2026

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?

Bug Report: Claude in Chrome Silently Executes Browser Commands on a Remote Device Without User Disclosure

Reported by: Martin Konye (martinkonye7@gmail.com)
Date: 2026-04-22
Product: Claude Desktop (Windows) + Claude in Chrome extension
Severity: High — Privacy & Security
Submit to: https://github.com/anthropics/claude-code/issues

---

Summary

When Claude Code uses the mcp__Claude_in_Chrome__* browser automation tools, commands are silently routed to a paired Chrome browser on a physically separate device via a WebSocket bridge hosted on claudeusercontent.com. The user receives no warning, no confirmation prompt, and no indication that the browser actions are executing on a different machine. Sensitive browser sessions — including third-party service credentials — are exposed to that other device and its screen without consent.

---

Steps to Reproduce

  1. Install Claude Desktop on Machine A (Windows).
  2. Install the Claude in Chrome extension on a Chrome browser on Machine B (a different physical device on the same network, or any network).
  3. Pair the extension to the Claude account — Machine B becomes the "personal chrome" paired device.
  4. On Machine A, open a Claude Code session and ask Claude to use browser automation (e.g., "log into Sentry and create alert rules").
  5. Observe: the browser opens and is controlled on Machine B, not Machine A.
  6. Claude completes all browser actions — including navigating to authenticated sessions and executing JavaScript — on the remote device with no warning shown on Machine A.

---

Observed Behavior

Claude executed browser commands on a different physical device ("personal chrome") without:

  • Any notification that a remote device would be used
  • Any confirmation prompt
  • Any indication in the UI of which device was targeted
  • Any way for the user to know this was happening without physically watching the other device

The user noticed because they saw their browser moving on a nearby machine. Had Machine B been in another room, office, or city, this would have been completely invisible.

---

Root Cause (from logs)

The mechanism is fully documented in the Claude Desktop log file at:
%APPDATA%\Claude\logs\main.log

1. Feature flag enables cloud bridge over local native messaging

[Chrome MCP] Bridge feature flag: chrome_ext_bridge_enabled_desktop=true, IS_NEST_BUILD=false

When this flag is true, Claude Desktop bypasses the locally installed native host binary (chrome-native-host.exe) and instead routes all browser commands through a WebSocket relay on Anthropic's infrastructure.

2. WebSocket bridge URL (from logs)

bridge_url: 'wss://bridge.claudeusercontent.com/chrome/d0b04acc-602c-4f71-bcb8-0d64681e7110'
[Claude in Chrome] Connecting to bridge: wss://bridge.claudeusercontent.com/chrome/d0b04acc-602c-4f71-bcb8-0d64681e7110

Both the Claude Desktop app (Machine A) and the Chrome extension (Machine B) connect to the same WebSocket endpoint on claudeusercontent.com. Commands flow:

Claude Code (Machine A)
        ↓
Claude Desktop app (Machine A)
        ↓
wss://bridge.claudeusercontent.com/chrome/<session-id>   ← Anthropic cloud relay
        ↓
Claude in Chrome extension (Machine B — "personal chrome")
        ↓
Browser actions execute on Machine B

3. Browser tool calls confirmed over bridge (from logs)

[EventLogging] Queuing event: chrome_bridge_connection_started
[EventLogging] Queuing event: chrome_bridge_connection_succeeded
[EventLogging] Queuing event: chrome_bridge_tool_call_started
[EventLogging] Queuing event: chrome_bridge_tool_call_completed

These log entries confirm that the browser tool calls (navigate, click, fill, screenshot, etc.) executed over the cloud bridge — not locally.

4. Paired device configuration (from claude_desktop_config.json)

"chromeExtension": {
  "pairedDeviceId": "4fdf659b-4202-4f25-bf19-a14fe77abff2",
  "pairedDeviceName": "personal chrome"
}

The config stores only the paired device name and ID. There is no field indicating physical location, network, or whether the device is local or remote. Claude Desktop has no logic to detect or warn when the paired device is not the local machine.

5. Native host registered for ALL browsers on Machine A but never used

The logs show extensive native host registration on Machine A:

[Chrome Extension MCP] Registering native host for Chrome in Windows registry
[Chrome Extension MCP] Registry verification successful for Chrome
[Chrome Extension MCP] Registering native host for Brave in Windows registry
[Chrome Extension MCP] Registry verification successful for Brave
[Chrome Extension MCP] Registering native host for Edge in Windows registry
... (Chromium, Arc, Vivaldi, Opera)
[Chrome Extension MCP] Native host installation complete

Yet when chrome_ext_bridge_enabled_desktop=true, this local native host (chrome-native-host.exe) is completely bypassed. The installation gives a false impression that browser automation will happen locally.

---

Security & Privacy Impact

| Risk | Description |
|------|-------------|
| Credential exposure | Third-party service sessions (Sentry, GitHub, banking, etc.) visible on an unattended remote screen during AI-driven navigation |
| No locality guarantee | The paired device can be in a different building, city, or country — "same network" is irrelevant to the bridge architecture |
| Third-party screen visibility | Anyone near Machine B during a session can observe all browser actions, including credentials, tokens, and session data |
| Transparent relay | All browser state (cookies, session tokens, DOM content) passes through bridge.claudeusercontent.com — a cloud intermediary |
| No revocation prompt | The bridge feature flag (chrome_ext_bridge_enabled_desktop) is controlled server-side; users cannot disable cloud routing from settings |
| Silent reconnect | Logs show the bridge auto-reconnects aggressively (up to 30s retry intervals) — sessions persist across network interruptions without re-consent |

---

Specific Incident

During a Claude Code session on 2026-04-22, I asked Claude to log into konye-consultants.sentry.io and create alert rules. Claude used mcp__Claude_in_Chrome__navigate, mcp__Claude_in_Chrome__javascript_tool, and related tools. All actions executed on "personal chrome" — a Chrome browser on a separate physical machine — via the bridge at:

wss://bridge.claudeusercontent.com/chrome/d0b04acc-602c-4f71-bcb8-0d64681e7110

I only became aware because I was physically present near the other device. Claude provided no warning before or during the session.

---

Expected Behavior

Before using browser automation tools, Claude should:

  1. Identify the target device — display the pairedDeviceName and whether it is local or remote.
  2. Require confirmation when remote — prompt: "Browser commands will be sent to 'personal chrome' — a paired device that may not be this machine. Continue?"
  3. Allow local-only mode — provide a setting to restrict browser automation to devices on the same machine or require explicit per-session opt-in for remote devices.
  4. Surface the bridge in UI — if the cloud bridge is active, indicate this in the Claude Desktop UI so users understand browser actions leave the local machine.

---

Environment

| Item | Value |
|------|-------|
| Claude Desktop version | (check Help → About) |
| OS | Windows 10 Pro 10.0.19045 |
| Bridge endpoint | wss://bridge.claudeusercontent.com |
| Feature flag | chrome_ext_bridge_enabled_desktop=true |
| Native host path | %APPDATA%\Claude\ChromeNativeHost\chrome-native-host.exe |
| Log file | %APPDATA%\Claude\logs\main.log |
| Config file | %APPDATA%\Claude\claude_desktop_config.json |

---

Log Evidence (excerpts from %APPDATA%\Claude\logs\main.log)

bridge_url: 'wss://bridge.claudeusercontent.com/chrome/d0b04acc-602c-4f71-bcb8-0d64681e7110'

[Chrome MCP] Bridge feature flag: chrome_ext_bridge_enabled_desktop=true, IS_NEST_BUILD=false

[Claude in Chrome] Connecting to bridge: wss://bridge.claudeusercontent.com/chrome/d0b04acc-602c-4f71-bcb8-0d64681e7110

[EventLogging] Queuing event: chrome_bridge_connection_started
[EventLogging] Queuing event: chrome_bridge_connection_succeeded
[EventLogging] Queuing event: chrome_bridge_tool_call_started
[EventLogging] Queuing event: chrome_bridge_tool_call_completed

[Claude in Chrome] Bridge connection closed (code: 1006, duration: 210196ms)
[Claude in Chrome] Bridge reconnecting in 2000ms (attempt 1)

What Should Happen?

well this is purely up to you

Error Messages/Logs

wss://bridge.claudeusercontent.com/chrome/d0b04acc-602c-4f71-bcb8-0d64681e7110

Steps to Reproduce

all in the description

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

latest

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗