`claude-in-chrome` extension fails to connect on Windows when Claude Desktop is also installed — workarounds insufficient

Summary

On Windows, the mcp__claude-in-chrome__* browser tools consistently fail with Browser extension is
not connected, even after applying the documented community workarounds. The root cause appears to be a
conflict between the native messaging hosts registered by Claude Desktop and Claude Code, compounded by
stale processes and named pipes that are not cleaned up.

## Environment

• OS: Windows 11 Pro 10.0.26200
• Chrome: 148.0.7778.97 (Official Build) (64-bit), Stable cohort (just auto-updated)
• Claude Code: running via C:\Users\<user>\.local\bin\claude.exe
• Claude Desktop: installed (UWP/AppX package, Claude_pzs8sxrjxfjjc)
• Chrome extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn (version 1.0.70_0)
• Extension status: installed, logged in, popup works, claude.ai/chrome reports it as healthy

## Steps to Reproduce

1. Install both Claude Desktop and Claude Code on Windows.
2. Install the Claude Chrome extension and log in at claude.ai.
3. From a Claude Code session, attempt to use any mcp__claude-in-chrome__* tool (e.g.

tabs_context_mcp).

## Expected

The tool returns the list of open tabs and the connection is established.

## Actual

``
Browser extension is not connected. Please ensure the Claude browser extension is installed and
running...
``

This persists indefinitely.

## Diagnosis

Both Claude Desktop and Claude Code register Chrome Native Messaging hosts in the user's Windows
registry:

```
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension
→ C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHo
st\com.anthropic.claude_browser_extension.json

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension
→ C:\Users\<user>\AppData\Roaming\Claude
Code\ChromeNativeHost\com.anthropic.claude_code_browser_extension.json
```

The Chrome extension appears to prefer the Desktop host, and the conflict prevents Claude Code from
acquiring the bridge.

## Workarounds Attempted (per community reports)

1. Renamed Claude Desktop's manifest to .json.disabled (equivalent of the macOS fix).
2. Killed the ghost cowork-svc.exe process (the Claude Desktop background service that keeps a socket

open even when the Desktop app is closed). Note: required Administrator privileges to kill —
Stop-Process from a normal shell returns Access Denied.

1. Fully closed and reopened Chrome.
2. Reloaded the extension at chrome://extensions/.
3. Restarted the Claude Code terminal.

Result: Connection still fails after all of the above.

## Additional Findings

After the workarounds, the named pipe still exists:

``
\\.\pipe\claude-mcp-browser-bridge-USER
``

But the extension can't connect to it. Multiple stale claude.exe processes accumulate across sessions
and are never cleaned up:

``
Id ProcessName StartTime
-- ----------- ---------
20224 claude 2026-05-11 19:59:11
21588 claude 2026-05-11 18:52:04
41812 claude 2026-05-11 19:34:29
41996 claude 2026-05-11 19:43:11
``

Running chrome-native-host.bat standalone for diagnostic purposes yields:

``
[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: \\.\pipe\claude-mcp-browser-bridge-USER
[Claude Chrome Native Host] Socket server error: ...
TypeError: Failed to listen at \\.\pipe\claude-mcp-browser-bridge-USER
code: "ERR_INVALID_ARG_TYPE"
``

This suggests the host fails to bind because the pipe is already held by a stale process, but the
binding error path is reported as ERR_INVALID_ARG_TYPE rather than EADDRINUSE, which is misleading.

## Suggested Improvements

1. Native host cleanup — when a Claude Code session exits, the native host should release the named

pipe. Currently stale claude.exe processes hold the pipe indefinitely.

1. Conflict detection — the Claude Code installer should detect Claude Desktop's host registration

and either coexist gracefully or warn the user.

1. Better error messages — ERR_INVALID_ARG_TYPE when the actual issue is a held pipe is hard to

diagnose. The host should detect existing-pipe situations and report them as such.

1. First-class fix for the Desktop/Code coexistence — the .json.disabled workaround is fragile and

requires manual intervention on every install. A first-class flag (e.g. claude code chrome --use and
--release) to switch which host owns the extension would be far more user-friendly.

## Reproducibility

100% — happens on every fresh attempt from this machine until the entire user session is rebuilt (kill
all claude.exe + cowork-svc.exe, then start fresh).