[BUG] Claude in Chrome doesn't connect when Claude Desktop is also installed

[zackbissell]

Preflight Checklist

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

What's Wrong?

• "Claude in Chrome doesn't connect when Claude Desktop is also installed"
• The bridge (tengu_copper_bridge) may need to be enabled for your account
• Chrome 145, extension v1.0.59, Claude Code 2.1.74, macOS

What Should Happen?

Both Claude Desktop and Claude Code should be able to use the Chrome extension simultaneously, or
at minimum, Claude Code's /chrome should connect when Desktop is installed.

Error Messages/Logs

Steps to Reproduce

1. Have both Claude Desktop and Claude Code installed
2. Install the Claude Chrome extension from the Web Store
3. Start Claude Code with claude --chrome
4. Run /chrome or call any mcp__claude-in-chrome__* tool
5. Observe: "Browser extension is not connected"

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.74 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment:

• Claude Code: 2.1.74
• Claude Desktop: 1.1.6041
• Chrome Extension: 1.0.59
• Chrome: 145.0.7632.160
• macOS 26.4 (arm64)

Steps to reproduce:

1. Have both Claude Desktop and Claude Code installed
2. Install the Claude Chrome extension from the Web Store
3. Start Claude Code with claude --chrome
4. Run /chrome or call any mcp__claude-in-chrome__* tool
5. Observe: "Browser extension is not connected"

Root cause (from debugging):
The Chrome extension tries native messaging hosts in order: com.anthropic.claude_browser_extension (Desktop) first,
then com.anthropic.claude_code_browser_extension (Code). Desktop's host responds to the ping first and wins the
connection. The Desktop native host (/Applications/Claude.app/Contents/Helpers/chrome-native-host) creates a Unix
socket at /tmp/claude-mcp-browser-bridge-{user}/{pid}.sock, but Claude Code cannot use this socket — the protocol
differs from what Claude Code expects.

The WebSocket bridge (wss://bridge.claudeusercontent.com) would allow both to coexist, but it's gated behind the
tengu_copper_bridge feature flag which does not appear to be enabled.

Workaround:
Rename the Desktop native messaging host config to let the extension fall through to Claude Code's host:
mv ~/Library/Application\ Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
~/Library/Application\ Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json.off
Then restart Chrome. This breaks Desktop's Chrome integration.

Expected behavior: Both Claude Desktop and Claude Code should be able to use the Chrome extension simultaneously, or
at minimum, Claude Code's /chrome should connect when Desktop is installed.

[cruzlauroiii]

Beyond the Desktop/CLI conflict, the tengu_copper_bridge feature flag can also cause "not connected" by forcing WebSocket bridge over local sockets. Even with Desktop removed, the bridge may fail. Patch to disable bridge in PR #34789.

[amttpoa]

Experiencing this same issue — Claude Code 2.1.76, macOS Darwin 25.3.0, Chrome with multiple profiles.

Environment:

• Claude Code CLI: 2.1.76
• Claude Desktop (Mac app): installed
• Chrome extension: v1.0.62 (installed in Profile 1, not Default)
• tengu_chrome_auto_enable: true in settings

What we tried (all failed):

1. Renamed Desktop's native host manifest to .disabled so only com.anthropic.claude_code_browser_extension.json remained — extension can't find it because it hardcodes connectNative("com.anthropic.claude_browser_extension")

2. Rewrote com.anthropic.claude_browser_extension.json to point path to Claude Code's binary (~/.claude/chrome/chrome-native-host) instead of Desktop's — Chrome spawns the native host, socket is created, but MCP client never connects to it

3. Changed Chrome's default profile (Local State → last_used: "Profile 1") to prioritize the profile with the extension installed — no effect

4. Verified the full chain works individually:

   • Native host process runs: ps aux shows /Users/x/.local/share/claude/versions/2.1.76 --chrome-native-host
   • Socket created: /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock
   • Socket is listening (lsof confirms)
   • But no Claude Code process connects to the socket — only the native host itself has an fd on it

Root issue: The socket handshake between the native host (spawned by Chrome) and the Claude Code MCP client is broken. The native host creates the socket and listens, but Claude Code's MCP server never discovers or connects to it. This worked on v2.1.37.

The tengu_copper_bridge WebSocket bridge mentioned in this thread — is there a way to enable it? That sounds like the right fix.

[stuarthallows]

Additional finding: MCP health check passes but tool execution fails (v2.1.77, macOS Darwin 25.3.0)

Environment:

• Claude Code: v2.1.77
• Chrome extension: v1.0.62 (fcoeoabgfenejglbffodgkkbkcdhcgfn)
• macOS Darwin 25.3.0
• Claude Desktop: not installed (previously removed)
• Chrome profile: Profile 4 with extension installed

Symptom:
/mcp shows claude-in-chrome as connected under "Built-in MCPs", but every tool call returns: "Browser extension is not connected."

Key finding — the bridge socket works perfectly:
The native host bridge at /tmp/claude-mcp-browser-bridge-<user>/<PID>.sock responds correctly to direct connections:

import socket, json, struct
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.connect('/tmp/claude-mcp-browser-bridge-<user>/<PID>.sock')
msg = json.dumps({'method': 'execute_tool', 'params': {'tool': 'tabs_context_mcp', 'args': {'createIfEmpty': True}}}).encode()
s.sendall(struct.pack('<I', len(msg)) + msg)
header = s.recv(4)
length = struct.unpack('<I', header)[0]
data = s.recv(length)
print(data.decode())
# Returns real tab data: {"result":{"content":[{"type":"text","text":"{\"availableTabs\":[...]}"}]}}

Tool calls via the bridge also work (e.g., navigate returns {"error":{"content":"No tab available"}} — correct error, not a connection failure).

Conclusion:
The MCP server's health check (/mcp → "connected") uses a different code path than actual tool execution. The health check passes, but tool execution never reaches the bridge socket. The "Browser extension is not connected" error is generated by the MCP server itself, not by the bridge or Chrome extension.

This is reproducible across fresh sessions with Chrome running before CC starts. The startup order workaround does not resolve it.