Claude-in-Chrome: connection fails when Claude Desktop installed despite disabling Desktop's native host (macOS)

[freema]

Description

claude-in-chrome MCP tools consistently return "Browser extension is not connected" despite all local infrastructure being correctly configured and functional. Claude Desktop is also installed on the system.

Environment

• Claude Code version: 2.1.76
• OS: macOS Darwin 24.5.0 (Apple Silicon)
• Chrome extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn
• Claude Desktop: installed

What was verified

Component	Status
Chrome extension installed & enabled	✅ Confirmed in chrome://extensions/
Extension ID matches	✅ fcoeoabgfenejglbffodgkkbkcdhcgfn
Native host binary exists & executable	✅ ~/.claude/chrome/chrome-native-host
Native host process running	✅ PID 82420 (claude 2.1.76 --chrome-native-host)
Unix socket created	✅ /tmp/claude-mcp-browser-bridge-*/82420.sock
hasCompletedClaudeInChromeOnboarding	✅ true
cachedChromeExtensionInstalled	✅ true
Desktop native host disabled	✅ Renamed to .disabled
External Extensions policy	✅ Not present (no force-install)

Root cause: tengu_chrome_auto_enable feature flag

The server-side GrowthBook feature flag tengu_chrome_auto_enable is set to false:

{
  "cachedGrowthBookFeatures": {
    "tengu_chrome_auto_enable": false
  },
  "claudeInChromeDefaultEnabled": true,
  "hasCompletedClaudeInChromeOnboarding": true,
  "cachedChromeExtensionInstalled": true
}

Manually setting tengu_chrome_auto_enable: true and claudeInChromeDefaultEnabled: true in ~/.claude.json does not resolve the issue — the flag appears to be enforced server-side regardless of local overrides.

What was tried (none helped)

1. ✅ Disabled Claude Desktop's native messaging host (com.anthropic.claude_browser_extension.json → .disabled)
2. ✅ Restarted Chrome (multiple times)
3. ✅ Restarted Claude Code CLI (multiple times)
4. ✅ Ran /chrome reconnect command
5. ✅ Manually set tengu_chrome_auto_enable: true in ~/.claude.json
6. ✅ Manually set claudeInChromeDefaultEnabled: true in ~/.claude.json
7. ✅ Verified same account on both CLI and claude.ai in Chrome

What was NOT tried (and why)

The workaround from #24593 (set Chrome as default browser → /login → re-auth) requires changing the default browser from Safari to Chrome, which is a significant disruption to the user's workflow. This should not be necessary for the feature to work.

Expected behavior

mcp__claude-in-chrome__tabs_context_mcp should connect to the Chrome extension when the native host is running and the socket is available, regardless of whether Claude Desktop is also installed.

Actual behavior

Every call returns: "Browser extension is not connected. Please ensure the Claude browser extension is installed and running..."

Related issues

• Claude Code Chrome integration fails to connect when Claude Desktop (Cowork) is also installed #29057 (main tracked issue — still OPEN)
• [BUG] Claude-in-Chrome: Browser extension persistently fails to connect from CLI #24593 (workaround found but requires changing default browser)
• Chrome extension connects to Claude desktop app instead of Claude Code when both native messaging hosts exist #24539 (Desktop/Code native host conflict)
• Claude-in-Chrome: Browser extension not connected despite correct setup #29528 (closed as duplicate of Claude Code Chrome integration fails to connect when Claude Desktop (Cowork) is also installed #29057)
• [BUG] Claude in Chrome doesn't connect when Claude Desktop is also installed #33483 (Desktop conflict)

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude in Chrome doesn't connect when Claude Desktop is also installed #33483
2. Claude Code Chrome integration fails to connect when Claude Desktop (Cowork) is also installed #29057
3. Chrome MCP server never auto-initializes without --chrome flag (macOS, v2.1.76) #34441

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[cruzlauroiii]

If Claude Desktop conflict is ruled out, check if tengu_copper_bridge feature flag is forcing WebSocket bridge — same symptom ("not connected" despite everything working locally). Fix in PR #34789.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.