[Bug] Claude in Chrome fails when Claude Desktop native messaging host config exists (macOS)

Status Closed — not planned

Reported on v2.1.17

Maintainer reply None cached

Activity 11 comments · opened Jan 23, 2026 · closed Apr 11, 2026

Description

Claude Code CLI cannot connect to the Chrome extension when Claude Desktop's native messaging host config file
exists, even if Claude Desktop is not running. The extension sidebar works fine, but CLI's MCP tools fail with
"Browser extension is not connected."

## Environment

Claude Code version: 2.1.17
macOS version: 26.2
Chrome extension version: (check yours)
Chrome version: (check yours)

## Root Cause

Both Claude Desktop and Claude Code register native messaging host configs for the same Chrome extension ID
(fcoeoabgfenejglbffodgkkbkcdhcgfn):

Desktop: `~/Library/Application

Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json`

Points to /Applications/Claude.app/Contents/Helpers/chrome-native-host
Creates socket in /tmp/claude-mcp-browser-bridge-*/

CLI: `~/Library/Application

Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json`

Points to ~/.claude/chrome/chrome-native-host (wrapper script)
Creates socket in $TMPDIR (/var/folders/.../T/claude-mcp-browser-bridge-{user})

Chrome preferentially loads Desktop's config (possibly alphabetical ordering), spawning Desktop's native host.
CLI's MCP looks for the socket in $TMPDIR, not /tmp/, so the connection fails.

## Steps to Reproduce

Have both Claude Desktop and Claude Code installed
Install the Claude Chrome extension
Run /chrome in Claude Code - shows "Status: Enabled"
Try to use any mcp__claude-in-chrome__* tool
Fails with "Browser extension is not connected"

## Diagnostic Commands

```bash
# Shows Desktop's native host running instead of CLI's
ps aux | grep chrome-native-host

# Desktop creates socket here:
ls -la /tmp/claude-mcp-browser-bridge-*/

# CLI expects socket here:
ls -la $TMPDIR/claude-mcp-browser-bridge-*

  Workaround

  Rename or remove the Desktop config:

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.bak

  Then restart Chrome. CLI will work, but Desktop's browser control will break.

  Expected Behavior

  Both Claude Desktop and Claude Code should be able to coexist and control Chrome, either:
  - Using separate extension IDs, or
  - Using a shared native host with consistent socket location, or
  - Having the MCP check both socket locations

  Additional Context

  The extension sidebar (within Chrome) works fine in both cases - only the external CLI/Desktop connection is
  affected.

View original on GitHub ↗

11 Comments

github-actions[bot] · 7 months ago

Found 3 possible duplicate issues:

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

dannyuk1982 · 7 months ago

The other issues do not refer to having the Desktop App open at the same time - which is key here.

tonydehnke · 7 months ago

Confirmed + additional findings

Your root cause analysis is spot-on. We hit the exact same issue and documented additional findings in #20341.

Key addition: Orphan native host process

Even when Claude Desktop is not running, Chrome starts Desktop's native host on launch because the extension auto-restores and requests native messaging.

Repro:

Reboot macOS
Do NOT open Claude Desktop app
Open Chrome (extension auto-restores)
ps aux | grep chrome-native-host shows /Applications/Claude.app/Contents/Helpers/chrome-native-host running

This means you can't avoid the conflict just by not running Desktop - you have to modify the config.

Confirmed workaround

Redirecting Desktop's config to Claude Code's native host works. Replace the contents of com.anthropic.claude_browser_extension.json to point path to ~/.claude/chrome/chrome-native-host instead of /Applications/Claude.app/....

Then pkill -f chrome-native-host and click the extension icon to reconnect.

Environment

macOS Darwin 25.2.0
Claude Code 2.1.19
Chrome 144.x

daniel-agentee · 7 months ago

not sure if I'm allowed to do this here, but thank you for that workaround, just saved my project!

MatheusSegalotto · 7 months ago

Workaround worked for me! Thank you very much

Nachx639 · 6 months ago

Fix: disable cloud bridge, use local socket

The root cause of the "Browser extension is not connected" / "Invalid token or user mismatch" error is a GrowthBook feature flag that forces the MCP server to use a cloud WebSocket bridge (wss://bridge.claudeusercontent.com) instead of the local Unix socket.

Quick fix — edit ~/.claude.json and set:

{
  "cachedGrowthBookFeatures": {
    "tengu_copper_bridge": false
  }
}

Then restart: claude --chrome

This bypasses the cloud bridge OAuth entirely and connects directly via the local socket. Full technical explanation here: https://github.com/anthropics/claude-code/issues/24593#issuecomment-3902208001

Note: The flag may revert to true periodically as it re-caches from Anthropic's servers. Just set it back to false if the error returns.

tink3rtanner · 6 months ago

Alternative workaround: symlink the socket path

If you don't want to modify native host configs, you can symlink the socket directly:

# Find the actual socket created by Desktop's native host
ls /tmp/claude-mcp-browser-bridge-$USER/

# Symlink it to where Claude Code expects it
ln -sf /tmp/claude-mcp-browser-bridge-$USER/*.sock $TMPDIR/claude-mcp-browser-bridge-$USER

This bridges the path mismatch without breaking either Desktop or CLI.

Caveat: The socket filename includes a PID (e.g., 80112.sock), so you'll need to re-run the symlink command if Chrome restarts and creates a new socket.

projectPDR · 5 months ago

Gave this to CC and it finally was able to make fix! Thanks 👍

bbopen · 5 months ago

Adding to this issue: even after resolving the Desktop vs Code native host conflict (by disabling Desktop's manifest), users still hit the tengu_copper_bridge GrowthBook flag issue.

The reliable combined fix for both problems is documented in #24935 — requires both disabling the Desktop manifest AND launching with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1.

Key finding: the chrome MCP runs in-process (not as a child subprocess), so editing ~/.claude.json while Claude Code is running has no effect. The env var prevents GrowthBook from overwriting the in-memory flag.

github-actions[bot] · 4 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.