Claude in Chrome: bridge feature flag blocks non-Chrome Chromium browsers from /chrome MCP integration

Summary

The Claude in Chrome extension's bridge WebSocket connection to bridge.claudeusercontent.com is blocked for non-Chrome Chromium browsers (Arc, Brave, Vivaldi, etc.) by a server-side feature flag. This prevents the /chrome MCP integration from working, even though:

• The extension installs and runs correctly
• Native messaging manifests are configured
• The native host spawns and creates a bridge socket
• The extension's side panel is fully functional
• The user is logged into the same claude.ai account in both Claude Code and the browser

Root Cause (analyzed)

The /chrome MCP integration does not use local Unix sockets. It communicates through a remote WebSocket bridge at wss://bridge.claudeusercontent.com.

The extension checks a feature flag chrome_ext_bridge_enabled via t.isFeatureEnabledAsync("chrome_ext_bridge_enabled"). The flag's default value is true (confirmed in chrome.storage.local on both Chrome and Arc). However, the server-side feature flag evaluation appears to return false for non-Chrome browsers, preventing the bridge WebSocket from being established.

Evidence from Arc browser (tested end-to-end):

| Check | Chrome | Arc |
|-------|--------|-----|
| Extension installed | Yes | Yes |
| Extension logged in (same account) | Yes | Yes |
| chrome_ext_bridge_enabled local default | true | true |
| bridgeDeviceId generated | Yes | Yes |
| bridge-keepalive alarm active | Yes | Yes |
| Bridge WebSocket actually connected | Yes | No |
| bridgeDisplayName set | Yes | Missing |
| mcpConnected | true | false |
| tabs_context_mcp works | Yes | "extension not connected" |

Architecture (as observed)

Claude Code (--chrome)
  └── MCP Server
       └── WSS → bridge.claudeusercontent.com ← WSS ── Chrome Extension
                                               ✗ WSS ── Arc Extension (blocked)

1. Claude Code's MCP server connects to the bridge via wss://bridge.claudeusercontent.com
2. The Chrome extension also connects to the bridge
3. The bridge matches them by OAuth user account
4. Tool calls (tabs_context_mcp, computer, etc.) flow through the bridge
5. Local bridge sockets (/tmp/claude-mcp-browser-bridge-*/) are NOT used for tool calls — they exist but the MCP server communicates exclusively through the remote bridge

For non-Chrome browsers, step 2 never happens because the feature flag blocks the WebSocket connection, so the MCP server finds no extension on the bridge.

How We Verified This

1. Installed the Claude extension in Arc (Chromium-based, same extension ID fcoeoabgfenejglbffodgkkbkcdhcgfn)
2. Confirmed native messaging works (ping/pong via connectNative)
3. Confirmed the extension's side panel is fully functional
4. Used socat MITM on the local bridge socket — no traffic passed through (proving local sockets aren't used)
5. Used lsof to confirm the MCP server connects to [2607:6bc0::10]:443 (bridge.claudeusercontent.com)
6. Used LOCAL_BRIDGE=1 to intercept the MCP protocol: {"type":"connect","client_type":"claude-code"}
7. Queried Arc's extension storage via CDP: bridgeDisplayName missing, mcpConnected: false, no bridge WebSocket resources
8. Compared with Chrome's extension: bridgeDisplayName present, mcpConnected: true, bridge connected

Proposed Fix

Remove the browser-type restriction from the chrome_ext_bridge_enabled feature flag evaluation. The extension already works correctly in Chromium-based browsers — only the bridge connection is blocked.

Alternatively, expose an environment variable (e.g. CLAUDE_CODE_CHROME_PATH) that allows the MCP server to fall back to local socket communication, bypassing the bridge entirely.

Environment

• macOS 15 (Darwin 25.3.0, ARM64)
• Claude Code 2.1.76
• Claude Extension 1.0.61
• Arc Browser (Chromium 146)
• Claude Max account (same account in CLI and browser)

Related Issues

• #18075 — Add env var for custom Chromium browser path
• #14536 — Allow browser selection instead of opening default browser
• #14370 — Detect extension in Chromium browsers
• #32976 — MCP fails to connect to Chromium browser

Related

Community workaround for native messaging manifests: claude-chromium-native-messaging