Claude in Chrome: MCP bridge fails to connect even with correct native host and socket (Desktop coexistence)

Environment

• Claude Code v2.1.80, macOS Darwin 25.1.0 (M4 MacBook Air)
• Claude in Chrome extension v1.0.63
• Chrome (managed profile, imaginariax.com)
• Claude Desktop also installed (auto-starts on boot)
• tengu_copper_bridge: false (pre-patched in ~/.claude.json)

Symptom

mcp__claude-in-chrome__tabs_context_mcp always returns "Browser extension is not connected" despite:

• Extension installed, enabled, v1.0.63
• Logged into claude.ai with correct account
• claude.ai tab open
• Native host process running with valid Unix socket

Diagnostic Steps Taken

1. Confirmed tengu_copper_bridge is false

python3 -c "import json; d=json.load(open('~/.claude.json')); print(d['cachedGrowthBookFeatures']['tengu_copper_bridge'])"
# False

2. Discovered Desktop vs Code native host conflict

Two native messaging manifests registered for the same extension ID (fcoeoabgfenejglbffodgkkbkcdhcgfn):

• com.anthropic.claude_browser_extension.json → /Applications/Claude.app/Contents/Helpers/chrome-native-host
• com.anthropic.claude_code_browser_extension.json → ~/.claude/chrome/chrome-native-host (→ Claude Code v2.1.80)

Chrome was launching Claude.app's native host. Confirmed via ps aux:

/Applications/Claude.app/Contents/Helpers/chrome-native-host chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/

3. Removed Desktop's manifest, restarted Chrome

After renaming com.anthropic.claude_browser_extension.json, Chrome correctly launched Claude Code's native host:

/Users/erich/.local/share/claude/versions/2.1.80 --chrome-native-host

Socket created at /tmp/claude-mcp-browser-bridge-erich/4789.sock (correct owner, 0600 permissions).

4. Still fails

Even with Claude Code's native host running and socket present, tabs_context_mcp still returns "Browser extension is not connected."

Root Cause Analysis

There appear to be three independent failure modes in Claude in Chrome:

1. tengu_copper_bridge forces WebSocket bridge with no local fallback (see #34788 analysis) — mitigated by pre-patching to false
2. Desktop and Code register competing native messaging hosts — Chrome picks Desktop's by default (see #20316, #33483)
3. Even after fixing (1) and (2), the MCP bridge layer inside Claude Code doesn't connect to the valid socket — this is the new finding

The third issue suggests the MCP server inside Claude Code (the layer that exposes mcp__claude-in-chrome__* tools) is not looking in /tmp/claude-mcp-browser-bridge-erich/ for the socket, or has an additional handshake/auth requirement that isn't being met.

Steps to Reproduce

1. Have both Claude Desktop and Claude Code installed on macOS
2. Reboot machine (Desktop auto-starts, registers its native host first)
3. Quit Desktop, start Claude Code
4. Open Chrome with Claude in Chrome extension enabled
5. Navigate to claude.ai, confirm logged in
6. Any mcp__claude-in-chrome__* tool call returns "not connected"

Even after removing Desktop's native messaging manifest and confirming Claude Code's native host creates a valid socket, the connection still fails.

Related Issues

• #20298 — canonical "not connected" issue (45 comments, 38 thumbs up, open since Jan 23)
• #20316 — Desktop coexistence conflict (native messaging host)
• #33483 — Desktop coexistence (duplicate)
• #34577 — still broken after disabling Desktop's native host (closest match)
• #34788 — best root cause analysis of tengu_copper_bridge code path
• #33880 — tengu_copper_bridge as sole root cause on macOS Intel
• #24935 — community-discovered tengu_copper_bridge workaround

Impact

Browser automation is unusable. Machine reboot, Chrome restart, extension toggle, Desktop quit, manifest removal — nothing resolves it. This has been reported by dozens of users across 40+ issues over 3 months with no fix shipped.