claude-in-chrome tools stay disconnected after Claude Desktop uninstall, even with healthy native host
Summary
After having both Claude Desktop app and Claude Code CLI installed (both registered Chrome native messaging hosts whitelisting the same extension), uninstalling the Desktop app and cleaning up its stale registration leaves Claude Code CLI unable to connect to the Chrome extension, even though:
- The correct CLI native host binary is running and listening on its socket
/mcpreports "Reconnected to claude-in-chrome" on each invocation- The Chrome extension is installed, running, and has no errors in its service worker
All mcp__claude-in-chrome__* tool calls return: Browser extension is not connected. Please ensure the Claude browser extension is installed and running...
Environment
- Claude Code version: 2.1.101
- macOS: Darwin 25.3.0 (arm64)
- Chrome extension: Claude for Chrome, ID
fcoeoabgfenejglbffodgkkbkcdhcgfn - Previously installed: Claude Desktop app (since uninstalled)
Reproduction
- Install Claude Code CLI and Claude Desktop app on the same machine
- Install the Claude for Chrome extension and pair with Claude Desktop
- Observe both native host JSON files present:
~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json→ points to CLI binary~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json→ points to/Applications/Claude.app/Contents/Helpers/chrome-native-host
- Both files whitelist the same extension ID
- The extension spawns the Desktop app's native host (
com.anthropic.claude_browser_extension), not the CLI's - Inside Claude Code CLI (
claude --chrome), anymcp__claude-in-chrome__*tool call fails with "extension not connected" - Uninstall Claude Desktop app (drag
/Applications/Claude.appto Trash) - Observe:
com.anthropic.claude_browser_extension.jsonis NOT removed by uninstall; orphan Desktop native host process still running - Manually remove stale JSON and kill orphan process
- Restart Chrome → fresh CLI native host spawns correctly at
/Users/$USER/.claude/chrome/chrome-native-host→2.1.101 --chrome-native-host - Socket is created at
/tmp/claude-mcp-browser-bridge-$USER/<pid>.sock - Run
/mcpin Claude Code CLI → reports "Reconnected to claude-in-chrome" - Bug:
mcp__claude-in-chrome__tabs_context_mcpstill returns "extension not connected" - Starting a fresh Claude Code session (
claude --chrome --continue) does not fix it
Diagnostic evidence
Native host process is healthy and correct:
Spencer 30300 /Users/Spencer/.local/share/claude/versions/2.1.101 --chrome-native-host
Socket exists and the native host is listening as server:
$ ls -la /tmp/claude-mcp-browser-bridge-Spencer/
srw------- 1 Spencer wheel 0 Apr 10 16:27 30300.sock
$ lsof -U | grep claude-mcp-browser
2.1.101 30300 Spencer 4u unix 0x2fe55ca9efce4386 0t0 /tmp/claude-mcp-browser-bridge-Spencer/30300.sock
Claude Code CLI session has 8 open unix sockets, none matching the native host's kernel address:
$ lsof -p 30733 | grep unix
2.1.101 30733 Spencer 10u unix 0x86fb3a3a1f2695d ->0xaa8e9767b44134e
2.1.101 30733 Spencer 15u unix 0xe703c1407595f04 ->0xbb71fcceeb8faa8f
2.1.101 30733 Spencer 17u unix 0x24b1cd9c3fc418b1 ->0xbc326801f15416f8
2.1.101 30733 Spencer 18u unix 0x4ceac7d720299d15 ->0x1861eae52c6ce846
2.1.101 30733 Spencer 19u unix 0x83c0a58246c40f44 ->0x50bf1a12c3715e7f
2.1.101 30733 Spencer 20u unix 0xc1a2438a5542d20e ->0x7cbf2877bc9444d0
2.1.101 30733 Spencer 22u unix 0x8600ac6864729481 ->0x4e4aa53d6df8c9f4
2.1.101 30733 Spencer 31u unix 0xcbc980a843931596 ->0xf20cb3ce36bc0ee0
None of the peer addresses match 0x2fe55ca9efce4386 (the native host's listening socket).
claude-in-chrome is not a registered stdio MCP server:
$ claude mcp list
context7: npx -y @upstash/context7-mcp - ✓ Connected
token-counter: npx -y token-counter-mcp - ✓ Connected
dual-graph: http://localhost:8080/mcp (HTTP) - ✗ Failed to connect
$ claude mcp get claude-in-chrome
No MCP server found with name: claude-in-chrome
So claude-in-chrome appears to be a built-in integration module, not a managed MCP subprocess, which means /mcp reconnect cannot restart it as a child process.
Chrome extension service worker shows no errors. Extension ID matches the allowed_origins field in com.anthropic.claude_code_browser_extension.json.
Expected behaviour
After the Desktop app is uninstalled and stale config files are removed, Claude Code CLI's built-in Chrome integration should connect to the fresh native host socket that Chrome is spawning, without requiring any additional user action beyond restarting Chrome and/or running /mcp.
Actual behaviour
The CLI side remains permanently "disconnected" from the native host, even though both sides are alive and the Chrome native host is running the correct CLI binary. /mcp reports success but no actual kernel-level socket connection is established.
Probable root causes (hypothesis)
- Uninstall cleanup gap: The Claude Desktop uninstaller does not remove
com.anthropic.claude_browser_extension.jsonor kill in-flight native host processes, leaving stale state that confuses the Chrome extension's backend selection. - Discovery / reconnect gap in the built-in chrome integration: The CLI's built-in Chrome integration module appears to cache a "disconnected" state at session startup and does not re-scan for new native host sockets when
/mcpis invoked, even though it reports reconnection success. - Silent backend selection inside the extension: The Chrome extension supports both
com.anthropic.claude_browser_extension(Desktop) andcom.anthropic.claude_code_browser_extension(CLI) but provides no user-visible toggle to switch between them.
Suggested fixes
- Claude Desktop uninstaller should remove
~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.jsonand terminate any runningchrome-native-hostprocesses owned by the Desktop app /mcpshould force the built-inclaude-in-chromeintegration to re-scan/tmp/claude-mcp-browser-bridge-$USER/and re-establish the kernel-level socket connection, not just report success- The Chrome extension should expose a settings UI to explicitly select "Claude Code" vs "Claude Desktop" as the backend, instead of silently picking one
Workaround
None found. The user cannot use mcp__claude-in-chrome__* tools in this state. Manually filling out web forms (the user's actual use case) becomes the only option.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗