[BUG] Claude in Chrome can't coexist with both Claude Desktop and Claude Code installed

Preflight Checklist

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

What's Wrong?

Environment

• macOS 15.1 (Darwin 25.1.0)
• Chrome stable (default profile)
• Claude for Chrome extension: v1.0.68, ID fcoeoabgfenejglbffodgkkbkcdhcgfn
• Claude Desktop: v1.3109.0
• Claude Code: v2.1.116

Summary

When both Claude Desktop and Claude Code are installed, the Chrome extension
always pairs with Claude Desktop. It cannot be used with Claude Code unless
the user manually removes or renames Claude Desktop's native-messaging-host
manifest. There is no user-facing way to choose the target.

Expected behavior

Either:

• The extension exposes a UI control to pick which local client (Desktop vs

Code) it pairs with, or

• It pairs with whichever client is currently running / has an active session,

or

• It maintains two simultaneous pairings and routes tool calls based on

origin.

Actual behavior

The extension's service worker has this hardcoded probe order (from
assets/service-worker.ts-Cw4emUEP.js in v1.0.68):

const s = [
  { name: "com.anthropic.claude_browser_extension",      label: "Desktop" },
  { name: "com.anthropic.claude_code_browser_extension", label: "Claude Code" },
];
for (const a of s) {
  try { const t = chrome.runtime.connectNative(a.name); ... } catch {}
}

It tries Desktop first. Because Claude Desktop's installer writes
com.anthropic.claude_browser_extension.json into Chrome's
NativeMessagingHosts/ directory, the connection succeeds and the loop exits.
Claude Code's native host (com.anthropic.claude_code_browser_extension) is
never reached, even when Claude Code is the process that actually needs the
browser bridge.

Reproduction

1. Install Claude Desktop (writes com.anthropic.claude_browser_extension.json)
2. Install Claude Code (writes com.anthropic.claude_code_browser_extension.json)
3. Install the Claude for Chrome extension
4. Quit Claude Desktop
5. In a Claude Code session, invoke any mcp__claude-in-chrome__* tool (e.g.

tabs_context_mcp)

Observed: the tool fails with

Browser extension is not connected. Please ensure the Claude browser extension
is installed and running (https://claude.ai/chrome)...

Diagnostics:

# Extension is connected, but to Desktop's host:
ps aux | grep chrome-native-host | grep -v grep
# → /Applications/Claude.app/Contents/Helpers/chrome-native-host chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/

Claude Code's native host binary
(/Users/<user>/.claude/chrome/chrome-native-host) is never spawned.

Workaround

Disable the Desktop manifest so the extension falls through to Claude Code:

mv "$HOME/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json" \
   "$HOME/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json.disabled"
# Reload the extension at chrome://extensions/
# Restart the Claude Code session (existing sessions cache the old bridge socket path)

After this, the extension pairs with Claude Code. Restore the Desktop manifest
when switching back.

Second caveat that makes this worse: existing Claude Code sessions seem to
cache the bridge socket path at startup. Even after renaming the manifest,
reloading the extension, and running /mcp ("Reconnected to
claude-in-chrome"), the session kept looking at the old (Desktop) socket.
Tool calls only started to work in a freshly started session.

Suggested fixes (any one)

1. Add a sidebar setting to pick the pairing target (Desktop / Code).
2. Make the native-host probe parallel rather than short-circuit on first

success, then let the user or the SDK select the correct endpoint.

1. Have Claude Code ship its manifest under the shared

com.anthropic.claude_browser_extension name when Desktop is absent, and
coordinate ownership when both are present.

1. On connectNative success, have the native host reply with a capability

descriptor; if the extension needs Code but gets Desktop, it should try
the next name.

1. Make /mcp reconnect in Claude Code re-run bridge-socket discovery rather

than just reconnecting the existing transport.

What Should Happen?

Expected behavior

Either:

• The extension exposes a UI control to pick which local client (Desktop vs

Code) it pairs with, or

• It pairs with whichever client is currently running / has an active session,

or

• It maintains two simultaneous pairings and routes tool calls based on

origin.

Error Messages/Logs

Steps to Reproduce

Reproduction

1. Install Claude Desktop (writes com.anthropic.claude_browser_extension.json)
2. Install Claude Code (writes com.anthropic.claude_code_browser_extension.json)
3. Install the Claude for Chrome extension
4. Quit Claude Desktop
5. In a Claude Code session, invoke any mcp__claude-in-chrome__* tool (e.g.

tabs_context_mcp)

Observed: the tool fails with

Browser extension is not connected. Please ensure the Claude browser extension
is installed and running (https://claude.ai/chrome)...

Diagnostics:

# Extension is connected, but to Desktop's host:
ps aux | grep chrome-native-host | grep -v grep
# → /Applications/Claude.app/Contents/Helpers/chrome-native-host chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/

Claude Code's native host binary
(/Users/<user>/.claude/chrome/chrome-native-host) is never spawned.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

• Claude for Chrome extension: v1.0.68, ID fcoeoabgfenejglbffodgkkbkcdhcgfn - Claude Desktop: v1.3109.0 - Claude Code: v2.1.116

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_