Claude-in-Chrome MCP: extension executes but CLI receives 'not connected' error (Windows)
Status Closed — not planned
Reported on v2.1.31
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 15 comments · opened Feb 4, 2026 · closed Apr 5, 2026
Bug Description
Claude-in-Chrome MCP extension is installed and enabled, but Claude Code CLI consistently receives "Browser extension is not connected" error, even though the extension actually executes the command on the Chrome side.
Steps to Reproduce
- Install Claude-in-Chrome extension in Chrome
- Verify extension status in Claude Code: Status: Enabled, Extension: Installed
- Run
/chromecommand — shows extension is configured - Call
tabs_context_mcp(or any othermcp__claude-in-chrome__*tool) - Chrome side shows the tool executed successfully (e.g., "Tabs read" appears in the extension UI)
- CLI receives error: "Browser extension is not connected"
Expected Behavior
The tool result should be returned to the CLI after successful execution in Chrome.
Actual Behavior
The extension processes the request (visible in Chrome UI as "Tabs read"), but the CLI always receives the generic "Browser extension is not connected" error message instead of the actual result.
Environment
- Claude Code version: 2.1.31
- OS: Windows 10/11
- Chrome: latest stable
- Extension: Claude-in-Chrome (installed via claude.ai/chrome)
Troubleshooting Attempted
- Reinstalled the extension
- Restarted Chrome multiple times
- Restarted Claude Code CLI multiple times
- Verified login on claude.ai
- Confirmed MCP status shows Enabled/Installed
Additional Context
The disconnect appears to be in the response path — the request reaches the extension and is executed, but the response does not make it back to the CLI. This suggests a possible WebSocket or message-passing issue on Windows.
15 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Root Cause Analysis
I make a little research and found that looks like the exact bug. The issue is a Windows-specific path mismatch between the native host and the MCP server's socket discovery logic.
How the architecture works
claude.exe --chrome-native-host) — started by Chrome via native messaging, creates a Windows named pipe server at:``
`\.\pipe\claude-mcp-browser-bridge-{username}
CN$()This is handled by the
function which correctly checksos.platform() === "win32"`.claude.exe --claude-in-chrome-mcp) — started by the CLI, needs to connect to the native host's pipe to forward tool calls.socketPath: CN$()→ correct:\.\pipe\claude-mcp-browser-bridge-{username}getSocketPaths: yZI→ broken on WindowsGlI()checks: ifgetSocketPathsexists → create a pool client (WlI). The pool client only usesgetSocketPaths()and ignoressocketPath.The bug
The
yZI()function (getSocketPaths) does not handle Windows. It returns Unix-style paths:Neither of these paths is the Windows named pipe
\.\pipe\claude-mcp-browser-bridge-{username}. The pool client tries to connect to non-existent Unix domain sockets, times out after 5 seconds, and returns "Browser extension is not connected."Meanwhile,
CN$()correctly handles Windows:The fix
Add Windows handling to
yZI():Evidence from debug logs
The named pipe exists and accepts connections (verified manually via
NamedPipeClientStream), but the MCP server never tries to connect to it becauseyZI()returns wrong paths.This affects all Windows users of Claude-in-Chrome. The same bug likely exists in issues #20862, #21404, and #21211.
Binary Patch for Windows (v2.1.31)
While waiting for an official fix, here is a same-length binary patch that fixes the
yZI()function directly inclaude.exe.What it does
Adds
if(Yy.platform()==="win32")return[CN$()];to thegetSocketPathsfunction so it returns the correct Windows named pipe path\.\pipe\claude-mcp-browser-bridge-{username}instead of non-existent Unix socket paths.patch-claude-chrome.js<details>
<summary>Click to expand patch script</summary>
</details>
Usage
patch-claude-chrome.jsclaude --chromeand verifyBy default it patches
%USERPROFILE%\.local\bin\claude.exe. To specify a different path:Rollback
Notes
.bakbackup before writingclaude updateFor v2.1.34 I updated the patched constants as follows, and it now works:
Root cause: \ missing Windows named pipe paths. The extension executes because the native host is running, but the MCP server can't connect back because it only looks for filesystem paths, not \ paths. Full analysis and fix: #23828
Workaround: Using Chrome-in-Windows from Claude Code in WSL
For those running Claude Code inside WSL but using Chrome on the Windows host (like me, OMG), you can bridge the Windows named pipe to a WSL Unix socket using
socat+npiperelay.exe.Architecture
Prerequisites
claude --chromerun at least once on Windows (to register the native host and create the pipe)``
bash
``sudo apt install socat
~/utils/:``
bash
``GOOS=windows GOARCH=amd64 go install github.com/jstarks/npiperelay@latest
cp ~/go/bin/windows_amd64/npiperelay.exe ~/utils/
1. Save the proxy script
2. Startup order
a) Start Claude on Windows (PowerShell/cmd):
Verify the named pipe exists:
b) Run the proxy in a separate WSL terminal:
c) Run Claude Code in another WSL terminal:
How it works
The proxy creates a Unix socket at
/tmp/claude-mcp-browser-bridge-{wsl_user}/{pid}.sock— the path where the MCP server scans for.sockfiles on Linux.socatlistens on this socket and for each connection runsnpiperelay.exeto forward traffic to the Windows named pipe\\.\pipe\claude-mcp-browser-bridge-{win_user}where the native host is listening.Verification
Check the proxy socket is listening:
Test the connection:
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
|
ECONNRESETon proxy test | Windows pipe has no listener | Startclaude --chromeon Windows first ||
ENOENTon proxy test | Proxy socket missing | Restart the proxy script || "Browser extension is not connected" | Proxy not running or pipe mismatch | Check proxy is running; verify WIN_USERNAME matches |
|
npiperelay.exenot found | Binary missing from~/utils/| Rebuild withGOOS=windows go install github.com/jstarks/npiperelay@latest|Comment for Related Issues (#23539, #23082, #21279, #20862)
---
Additional Root Cause: Windows Username Spaces
I've discovered a third independent bug affecting Windows users with spaces in their usernames (e.g., "John Smith", "Dennis Bosma").
The Problem
Pipe name mismatch:
This causes MCP tools to fail with "Browser extension is not connected" even when:
Why This Matters
This bug persists EVEN AFTER applying existing workarounds:
This explains why some users report success with the Node.js + getSocketPaths() patch, but others still fail — it depends on whether they have spaces in their Windows username.
The Fix (One Line)
Add username sanitization in both native host and MCP client:
Test Evidence
Direct pipe connection test confirms the pipe with space exists:
But MCP tools search for the sanitized version (without space) and fail.
Affected Users
Full Diagnosis
See Issue #23828 for comprehensive diagnosis, test evidence, and proposed fixes.
---
TL;DR: If you have spaces in your Windows username, the existing Bun + getSocketPaths() fixes won't help. You need username sanitization in the pipe name generation.
Since we don't seem to be getting an upstream patch for this anytime soon, I've had claude generalise the original patch to survive basic recompiles. If the underlying code actually changes, this will break - but hopefully at that point this will be fixed.
Update: ESM Bug & Two Patch Approaches (v2.1.37)
New finding: ESM module incompatibility
cli.js in v2.1.37 uses
"type": "module"(ESM). Any patch usingrequire("os")orrequire("path")will throwReferenceError: require is not definedat runtime. Useprocess.platformandprocess.env.USERNAMEinstead — these are process globals available in both CJS and ESM.Two complementary approaches
1. Binary patch for
claude.exe(by @rvwcs-jimt above)claude.exeif(osMod.platform()==="win32")return[pipeFn()]early return2. cli.js text patch via npm wrapper (our approach in #23828)
cli.json disk (both npm global and isolated Chrome install)claude.cmd(npm global wrapper) instead ofclaude.execlaude-mcp-browser-bridge, brace counting)if(process.platform==="win32"){let W=\\\.\pipe\claude-mcp-browser-bridge-${process.env.USERNAME||"default"}\;if(!A.includes(W))A.push(W)}Both confirmed working end-to-end on Windows v2.1.37.
I think this is fixed now? The patch no-longer applies and I can connect claude to chrome without it.
What is your version?
@rvwcs-jimt What version are you on? As of v2.1.39, the upstream code still doesn't include Windows named pipe paths in
getSocketPaths(). If the old patch no longer applies, it's likely because the minified function name changed between versions (it goes fromGc4tocc4to$c4etc. on each release).The fix I maintain uses content-based pattern matching (anchors on the
claude-mcp-browser-bridgestring, not function names) so it survives across versions.Published fix: bosmadev/claude —
scripts/fix-chrome-native-host.pyRuns as a SessionStart hook, auto-repairs on every launch. Fixes all 3 Windows Chrome bugs (Bun crash, socket path discovery, bridge exclusive mode). See #23828 for details.
when this bug is going to get fixed?
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
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.