[Bug] Chrome Extension (claude-in-chrome) broken on Windows since v2.1.20 - Named Pipe path missing in getSocketPaths
Title: [Bug] Chrome Extension (claude-in-chrome) broken on Windows since v2.1.20 - Named Pipe path missing in getSocketPaths
---
Describe the bug
Since v2.1.20, the Chrome Extension MCP (claude-in-chrome) no longer connects on Windows. The extension sidebar shows "Waiting for Claude Code..." indefinitely. All browser automation tools (tabs_context_mcp, navigate, read_page, etc.) fail.
To reproduce
- Install Claude Code 2.1.20+ on Windows
- Install the Chrome Extension "Claude in Chrome"
- Run
claude --chrome - Try
tabs_context_mcp→ fails, extension never connects
Root cause found
The function xQ4() (getSocketPaths) in cli.js returns socket paths for the MCP Socket Pool to search. On Windows, it only returns Unix-style paths:
C:\Users\<user>\AppData\Local\Temp\claude-mcp-browser-bridge-<username>/tmp/claude-mcp-browser-bridge-<username>
But the native host (Rj6()) creates a Windows Named Pipe at:
\\.\pipe\claude-mcp-browser-bridge-<username>
The Named Pipe path is never added to the search list, so the Socket Pool can never find it.
Why it worked in v2.1.19: socketPath was resolved directly (via _Z6(context)), not through the Socket Pool. The migration to the Socket Pool (gKq via QKq) broke Windows.
Fix
Add the Windows Named Pipe path to xQ4():
// Add before "return A" in xQ4():
if(TNY()==="win32"){let w=`\\\\.\\pipe\\${K}`;if(!A.includes(w))A.push(w)}
TNY() is the already-available minified os.platform(). This adds \\.\pipe\claude-mcp-browser-bridge-<username> to the socket search list on Windows only.
Full patch details in this gist: https://gist.github.com/alex2zimmermann-ux/c4532b4f8b94640c6cde81c7f7552d8e
Expected behavior
Chrome Extension should connect and browser automation tools should work on Windows.
Environment
- OS: Windows 10/11
- Claude Code version: 2.1.20+ (broken), 2.1.19 (worked)
- Shell: Git Bash / PowerShell
- Chrome Extension: Claude in Chrome (latest)
Additional context
The fix is minimal (one line) and only affects Windows. Unix/macOS paths remain unchanged. Verified working after applying the patch.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗