Claude in Chrome extension not connecting despite being installed and enabled

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/21337
2. https://github.com/anthropics/claude-code/issues/21240
3. https://github.com/anthropics/claude-code/issues/21363

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

same issue here. downgrading now

@plejsq which version should i downgrade to?

Same issue. 4 days ago this wasn't an issue. Not sure if it's Claude Code (v 2.1.19 was fine) or the extension

<img width="1589" height="894" alt="Image" src="https://github.com/user-attachments/assets/4702431e-7831-4ad2-8eca-869884c4e59f" />

Same problem on Windows 11 ! No problem on my Mac or Ubuntu.

Same issue. Windows 11. Claude Code CLI.
Troubleshooting attempted:

• Disable/Enable MCP
• Reinstall Chrome Extension
• Restart Chrome

Issue persists

Reverting to Claude code v 2.1.19 worked for me!

IMPORTANT: in addition to reverting back to v2.1.19 you also need to remove the current version or else Claude code will default to the latest version - you can see if you were succesful at reverting by running claude --version

Same issue

same issue on Windows 11.
Troubleshooting attempted:

• Disable/Enable MCP
• Reinstall Chrome Extension
• Restart Chrome
• reinstall claude code (with and without clearing %USERPROFILE%/.claude/)

Issue persists

Is this thread only about Win 11? I'm on MacOS and seem to have this problem too.

Downgraded to v2.1.19 and it works again (on Windows 11)

Any fix to this?

Same issue and had to downgrade to v2.1.19 to work. Tried various ways seems nothing works.

Root cause found and documented in #21791: The \ function (socket path discovery) doesn't return Windows named pipe path. Fix: add \ at the start of the function.

See detailed analysis: https://github.com/anthropics/claude-code/issues/21791#issuecomment-3838702991

Root cause found and documented in #21791: The \ function (socket path discovery) doesn't return Windows named pipe path. Fix: add \ at the start of the function. See detailed analysis: #21791 (comment)

Nice work! This fix worked for me. I can now use the Claude Code Chrome extension with v2.1.29 of Claude Code on Windows 11

✅ Workaround Confirmed Working (Windows 11, Claude Code 2.1.29)

Root cause identified by @kimchi-developer in #21791 — the xQ4() function (socket path discovery) doesn't return Windows named pipe
path.

### Quick Fix

1. Backup cli.js:
```bash
copy "%LOCALAPPDATA%\..\Roaming\npm\node_modules\@anthropic-ai\claude-code\cli.js"
"%LOCALAPPDATA%\..\Roaming\npm\node_modules\@anthropic-ai\claude-code\cli.js.backup"

1. Find your cli.js location:

where claude
Then navigate to node_modules\@anthropic-ai\claude-code\cli.js in that path.

1. Apply patch:

Search for the socket path function. In v2.1.29 it's named xQ4 (minified names vary between versions):

Find:
function xQ4(){let A=[],q=gm1()

Replace with:
function xQ4(){if(TNY()==="win32")return[\\\\.\\pipe\\${yNY()}];let A=[],q=gm1()

1. After patching:

• Restart Chrome completely
• Start new Claude Code session
• Run /chrome to initialize the MCP
• Test with any mcp__claude-in-chrome__* tool

Finding the right function (if name differs)

Search for claude-mcp-browser-bridge in cli.js. You'll find functions like:

• gm1() — returns Unix temp path
• Rj6() — has Windows named pipe (correct)
• xQ4() or similar — returns socket paths array (BROKEN on Windows)

The broken function scans for .sock files but never adds the Windows named pipe. The fix adds Windows detection at the start.

⚠️ Note

Patch will be lost on Claude Code update. Re-apply after upgrading until this is fixed upstream.

Credit: @kimchi-developer for root cause analysis, @plejsq for the fix template.

Still broken on v2.1.31 (Windows 11, build 10.0.26100).

I've traced the root cause to a socket path mismatch between the two processes:

The native host (--chrome-native-host) tries Unix-style socket paths:

• C:\Users\<user>\AppData\Local\Temp\claude-mcp-browser-bridge-<user>
• /tmp/claude-mcp-browser-bridge-<user>

Both fail with ENOENT. From the debug log (~/.claude/debug/*.txt):

[Claude in Chrome] Attempting to connect to: C:\Users\rsacc\AppData\Local\Temp\claude-mcp-browser-bridge-rsacc
[Claude in Chrome] Attempting to connect to: /tmp/claude-mcp-browser-bridge-rsacc
[Claude in Chrome] Socket error (code: ENOENT): Error: connect ENOENT ...
[Claude in Chrome] No connected sockets in pool
[Claude in Chrome] Server is connected: false.

But the CLI MCP server (--claude-in-chrome-mcp) creates a Windows named pipe at \.\pipe\claude-mcp-browser-bridge-rsacc.

Verified the named pipe is functional:

• Get-ChildItem \.\pipe\ | Where-Object Name -like '*claude*' shows the pipe exists
• A test Node.js script connecting to \.\pipe\claude-mcp-browser-bridge-rsacc succeeds and gets valid JSON-RPC responses

The native host simply never attempts the \.\pipe\ path, so the two processes never connect.

Fix needed: On Windows, the native host should try \.\pipe\claude-mcp-browser-bridge-{username} instead of (or in addition to) the Unix socket paths.

Adding to the above — this bug has been open for months now and affects every Windows user trying to use Chrome integration. It's one of the most compelling features of Claude Code, and Windows users are completely locked out of it.

Please don't leave the Windows community behind Mac users. We'd really appreciate a fix for this. The root cause is well-understood (named pipe vs Unix socket path mismatch) — it should be a straightforward fix on the native host side.

I always get the following on my mac

It looks like the Claude in Chrome extension isn't currently connected. To use Chrome browser automation, you'll need to reconnect it.
Here's how to fix this:

Make sure you're logged into the same account in both Claude Desktop and the Claude in Chrome extension
If that doesn't work, restart Chrome completely (close all windows and reopen)
If it's still not connecting, restart Claude Desktop as well

Once the extension is reconnected, I'll be able to navigate to Google Calendar and check your schedule for the week. Would you like to try reconnecting?

✅ Complete Windows Fix Guide — Chrome Extension "Not Connected"

UPDATE (Feb 11): v2.1.38+ fixes the named pipe issue upstream. The standalone exe works fine now — npm installation is NOT required and can actually break your setup (see warning below). You only need to fix chrome-native-host.bat.

---

The Problem

Three issues used to prevent Chrome extension from working on Windows:

| # | Issue | Cause | Status |
|---|-------|-------|--------|
| 1 | Standalone exe crashes (Segfault) | Bun v1.3.9-canary.51 runtime bug on Windows | ✅ Fixed in v2.1.38+ |
| 2 | chrome-native-host.bat points to wrong binary | Auto-generated, may reference wrong path | ⚠️ Needs manual fix |
| 3 | Named pipe mismatch | Socket discovery didn't return \\.\pipe\ path | ✅ Fixed in v2.1.38+ |

---

✅ Recommended Fix (v2.1.38+) — Standalone exe only, no npm

⚠️ WARNING: Do NOT use npm install -g @anthropic-ai/claude-code The earlier version of this guide recommended npm installation. This can cause serious PATH conflicts and PowerShell alias issues, leaving you with a broken claude command pointing to a non-existent claude.cmd. If you already did this, see the "Recovering from npm install" section below.

Prerequisites

• Claude Code v2.1.38+ (standalone installer)
• Chrome with Claude in Chrome extension

Step 1 — Verify your version

& "$env:USERPROFILE\.local\bin\claude.exe" --version
# ✅ Should show: 2.1.38+ (Claude Code)

Step 2 — Fix chrome-native-host.bat

$claudePath = "$env:USERPROFILE\.local\bin\claude.exe"
@"
@echo off
"$claudePath" --chrome-native-host
"@ | Set-Content "$env:USERPROFILE\.claude\chrome\chrome-native-host.bat"

Step 3 — Restart & test

1. Close Chrome completely (kill all chrome.exe processes in Task Manager)
2. Open Chrome
3. Run claude in a new terminal
4. Chrome extension should connect ✅

---

⚠️ WindowsApps\Claude.exe vs .local\bin\claude.exe

where.exe claude may show multiple entries. If WindowsApps\Claude.exe appears first and gives errors (like fs.Stats deprecation with no output), the wrong binary is running. Fix by adding to your PowerShell profile:

Add-Content $PROFILE 'Set-Alias -Name claude -Value "$env:USERPROFILE\.local\bin\claude.exe" -Force -Scope Global'

Then restart PowerShell.

---

🔧 Recovering from npm install

If you followed the old version of this guide and ran npm install -g @anthropic-ai/claude-code, your claude command may be broken. Symptoms:

• claude.cmd is not recognized
• Claude launches but immediately exits
• PATH shows npm\claude.cmd that doesn't work

Fix:

# 1. Remove broken alias from PowerShell profile (if added)
(Get-Content $PROFILE) | Where-Object { $_ -notmatch 'Set-Alias.*claude.*npm' } | Set-Content $PROFILE

# 2. Remove alias from current session
Remove-Alias claude -Force -ErrorAction SilentlyContinue

# 3. Uninstall npm version
npm uninstall -g @anthropic-ai/claude-code 2>$null

# 4. Point to correct exe
Add-Content $PROFILE 'Set-Alias -Name claude -Value "$env:USERPROFILE\.local\bin\claude.exe" -Force -Scope Global'

# 5. Reload profile
. $PROFILE

# 6. Verify
claude --version
# → 2.1.39 (Claude Code)

---

<details>
<summary><strong>🔧 Legacy: Binary patch for standalone exe users (pre-v2.1.38)</strong></summary>

If you must use the standalone installer and are on a version before v2.1.38, paste this prompt into Claude Code to self-patch:

Fix the Chrome extension "Browser extension is not connected" bug on Windows by binary-patching claude.exe.

The issue: The socket path discovery function (minified name varies per version, e.g. iYI, xQ4, etc.) in claude.exe only scans for Unix .sock files and never returns the Windows named pipe path. The server-side function (which creates the pipe) correctly handles Windows, but the discovery/client function doesn't.

Steps to follow:
1. Find claude.exe location (check `where claude` or ~/.local/bin/claude.exe)
2. Search the binary for "claude-mcp-browser-bridge" to find the relevant functions
3. Identify the BROKEN function: it's the one that creates an array, scans for .sock files with readdirSync, and returns paths array — but has NO Windows/win32 check. It looks like: function XXX(){let H=[],$=YYY();try{let I=ZZZ.readdirSync($);for(let f of I)if(f.endsWith(".sock"))...}catch{}...return H}
4. Identify the WORKING server function nearby: it HAS a win32 check and returns a named pipe like `\.\pipe\name`. Note the exact pipe path template literal bytes from this function.
5. Create a backup: claude.exe.pre-chrome-patch
6. Build a replacement of EXACTLY the same byte length by:
   - Adding `if(PLATFORM_CHECK==="win32")return[PIPE_PATH];` at the start of the function body (use the same platform function and pipe path format from the working server function)
   - Removing redundant Unix-only code (like the /tmp duplicate path check) to compensate for added bytes
   - Padding with spaces before `return` if needed to match exact length
7. Since claude.exe is running, rename it to claude.exe.running first, then write the patched version as claude.exe
8. Verify: patched functions found = 2, original remaining = 0, file size unchanged

Use Python with explicit byte construction (b'\x5c' for backslashes) to avoid escaping issues. The pipe path must have exactly 4 backslash bytes before the dot and 2 before "pipe" and before "${...}" — match the working function's bytes exactly.

</details>

---

Verification Checklist

# Correct binary
& "$env:USERPROFILE\.local\bin\claude.exe" --version
# → 2.1.39 (Claude Code)

# Bat file is correct
Get-Content "$env:USERPROFILE\.claude\chrome\chrome-native-host.bat"
# → should reference .local\bin\claude.exe --chrome-native-host

Troubleshooting

| Symptom | Fix |
|---------|-----|
| claude.cmd is not recognized | You ran npm install — see "Recovering from npm install" above |
| fs.Stats deprecation + no output | Wrong binary (WindowsApps\Claude.exe). Use .local\bin\claude.exe instead |
| "Extension not connected" | Re-check chrome-native-host.bat content |
| Disconnects immediately | Kill ALL chrome.exe processes, restart Chrome + Claude |
| Cache access denied error | Run Remove-Item "$env:LOCALAPPDATA\claude" -Recurse -Force and retry |

---

Credits: Root cause analysis in #21791 by @kimchi-developer. Community workarounds by @hara94, @ArtyMcLabin, @DanielKerridge, @robsaccone.

I've created a Claude command + patch script that fixes this automatically on Windows. I run /patch-chrome after every Claude Code update and Chrome MCP works fine on Win 11.

Claude command (.claude/commands/patch-chrome.md):

~~~
---
description: Patch Claude Code CLI to fix Chrome MCP on Windows
allowed-tools: Bash
---

Apply the Windows named-pipe fix for the Chrome MCP extension connection issue.

See: https://github.com/anthropics/claude-code/issues/21371

Command

Run the patch script:

node .claude/patch-chrome-mcp.js

If the user passes --restore as an argument, restore the original:

node .claude/patch-chrome-mcp.js --restore

Report the output. If the patch was applied, remind the user to:

1. Restart Chrome completely
2. Start a new Claude Code session
3. Run /chrome to initialize the MCP

~~~

Patch script (.claude/patch-chrome-mcp.js):

<details>
<summary>Click to expand</summary>

#!/usr/bin/env node
//
// patch-chrome-mcp.js
//
// Fixes Claude Code CLI on Windows where the Chrome MCP extension
// fails to connect. The socket-discovery function scans for .sock
// files (Unix-only) instead of returning the Windows named pipe.
//
// This patch adds an early return on win32 so the function returns
// the correct named pipe path: \\.\pipe\claude-mcp-browser-bridge-<user>
//
// Usage:  node scripts/patch-chrome-mcp.js
//         node scripts/patch-chrome-mcp.js --restore
//
// See: https://github.com/anthropics/claude-code/issues/21371

const fs = require("fs");
const os = require("os");
const path = require("path");

const cliPath = path.join(
  os.homedir(),
  "AppData",
  "Roaming",
  "npm",
  "node_modules",
  "@anthropic-ai",
  "claude-code",
  "cli.js"
);
const backupPath = cliPath + ".backup";

// ── Restore mode ──────────────────────────────────────────────
if (process.argv.includes("--restore")) {
  if (!fs.existsSync(backupPath)) {
    console.error("No backup found at:", backupPath);
    process.exit(1);
  }
  fs.copyFileSync(backupPath, cliPath);
  console.log("Restored cli.js from backup.");
  process.exit(0);
}

// ── Patch mode ────────────────────────────────────────────────
if (!fs.existsSync(cliPath)) {
  console.error("cli.js not found at:", cliPath);
  console.error("Is Claude Code installed via npm?");
  process.exit(1);
}

console.log("Reading:", cliPath);
let content = fs.readFileSync(cliPath, "utf-8");

const pipeFunc = content.match(
  /function\s+(\w+)\(\)\{if\((\w+)\(\)==="win32"\)return`/
);

if (!pipeFunc) {
  console.error("Could not find the named-pipe function.");
  console.error("The minified code structure may have changed.");
  process.exit(1);
}

const pipeFuncName = pipeFunc[1];
const platformFn = pipeFunc[2];
console.log(`Found pipe function: ${pipeFuncName}()`);
console.log(`Found platform function: ${platformFn}()`);

const pipeIdx = content.indexOf(pipeFunc[0]);
const pipeContext = content.substring(pipeIdx, pipeIdx + 200);
const pipeNameMatch = pipeContext.match(/pipe\\\\\$\{(\$?\w+)\(\)\}/);

if (!pipeNameMatch) {
  console.error("Could not find the pipe-name function in template literal.");
  console.error("Context:", pipeContext.substring(0, 150));
  process.exit(1);
}

const pipeNameFn = pipeNameMatch[1];
console.log(`Found pipe-name function: ${pipeNameFn}()`);

const sockFunc = content.match(
  /function\s+(\w+)\(\)\{(?:if\(\w+\(\)==="win32"\)[^;]+;)?let \w+=\[\],\w+=(\w+)\(\);try\{let \w+=\w+\(\w+\);for\(let \w+ of \w+\)if\(\w+\.endsWith\("\.sock"\)\)/
);

if (!sockFunc) {
  console.error("Could not find the socket-paths function.");
  console.error("The minified code structure may have changed.");
  process.exit(1);
}

const sockFuncName = sockFunc[1];
console.log(`Found socket-paths function: ${sockFuncName}()`);

const alreadyPatched = content.includes(
  `function ${sockFuncName}(){if(${platformFn}()==="win32")`
);
if (alreadyPatched) {
  console.log("\nAlready patched! Nothing to do.");
  process.exit(0);
}

fs.copyFileSync(cliPath, backupPath);
console.log("Backup created:", backupPath);

const returnMatch = pipeContext.match(/return(`[^`]+`)/);
if (!returnMatch) {
  console.error("Could not extract return value from pipe function.");
  process.exit(1);
}
const pipeReturnExpr = returnMatch[1];

const searchStr = `function ${sockFuncName}(){let`;
const patchedStr = `function ${sockFuncName}(){if(${platformFn}()==="win32")return[${pipeReturnExpr}];let`;

console.log(`\nSearch:  ${searchStr}`);
console.log(`Replace: ${patchedStr.substring(0, 120)}...`);

if (!content.includes(searchStr)) {
  console.error(`\nCould not find "${searchStr}" in cli.js`);
  process.exit(1);
}

content = content.replace(searchStr, patchedStr);
fs.writeFileSync(cliPath, content, "utf-8");

const verify = fs.readFileSync(cliPath, "utf-8");
if (
  verify.includes(
    `function ${sockFuncName}(){if(${platformFn}()==="win32")`
  )
) {
  console.log("\nPATCH APPLIED SUCCESSFULLY");
  console.log("\nNext steps:");
  console.log("  1. Restart Chrome completely");
  console.log("  2. Start a new Claude Code session");
  console.log("  3. Run /chrome to initialize the MCP");
} else {
  console.error("\nPatch verification failed!");
  process.exit(1);
}

</details>

@morphaven @hara94 Thank you! I've been dealing with this issue for over a week, hoping Anthropic would fix it. The Chrome plugin used to work perfectly, and it was easy to get used to. Your fix works for me, so you've made my day!

Was having hard time since the update. The fix had helped me. I just get claude to work the fix with referencing to this thread. It works like charm. But its definately not a permanent fix. Hopefully claude fix it.

That was quite the journey. To recap what we fixed:

1. Bun crash — The native installer's Bun v1.3.9-canary.51 crashes on Windows. Fixed by installing Claude Code via npm

instead (npm install -g @anthropic-ai/claude-code)

1. Bat file pointing to old binary — Updated chrome-native-host.bat to use Node.js instead of the crashing Bun exe
2. Windows named pipe bug — The core issue: cc4() (socket path discovery) never returns the Windows \\.\pipe\ path, so

the MCP client could never find the native host's pipe. Patched cli.js to return the correct pipe path on Windows.

Important: The cli.js patch will be lost when Claude Code updates. You can re-apply it by running:
node patch-chrome-mcp.js

The full file:

const fs = require('fs');
const cliPath = 'C:/Users/RadiumPCs/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js';

// Restore from backup first
fs.copyFileSync(cliPath + '.backup', cliPath);

let src = fs.readFileSync(cliPath, 'utf8');

// Find the broken function
const oldFn = 'function cc4(){let A=[],q=uQ1()';
if (!src.includes(oldFn)) {
  console.log('ERROR: Could not find target function');
  process.exit(1);
}

// Copy the exact pattern from tW6 which works:
// function tW6(){if(QCY()==="win32")return`\\\\.\\pipe\\${lCY()}`;
// So the fix for cc4 should return an array with that same path
const newFn = 'function cc4(){if(QCY()==="win32")return[`\\\\\\\\.\\\\pipe\\\\${lCY()}`];let A=[],q=uQ1()';

src = src.replace(oldFn, newFn);
fs.writeFileSync(cliPath, src);

// Verify
const verify = fs.readFileSync(cliPath, 'utf8');
const idx = verify.indexOf('function cc4()');
const snippet = verify.substring(idx, idx + 150);
console.log('Patched function:', snippet);

// Test what the template literal would produce
const testPipeName = 'claude-mcp-browser-bridge-test';
const expected = `\\\\.\\pipe\\${testPipeName}`;
console.log('Expected pipe format:', expected);
console.log('Patch applied successfully!');

Paste this into claude code and it will fix it

on mac
/chrome
❯ Claude in Chrome (Beta)

Claude in Chrome works with the Chrome extension to let you control your browser directly from Claude Code. Navigate websites, fill
forms,
capture screenshots, record GIFs, and debug with console logs and network requests.

Status: Enabled
Extension: Installed

⏺ Claude in Chrome[tabs_context]
⎿  Error: No Chrome extension connected.

The same issue appeared on MacOS.

same issue on macOS

same on Linux

claude --version
2.1.42 (Claude Code)

$ uname -a
Linux fedora 6.18.7-200.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jan 23 16:42:34 UTC 2026 x86_64 GNU/Linux

same on mac 17/02/2026

same on mac 17/02/2026

still a issue here

Same issue on Mac

Here's a good description of the bug and also the fix that worked for me: https://x.com/dguido/status/2015675500799173013

sme issue on mac

After trying few things as outlined in the twitter link above, checked debug logs (~/.claude/debug/) for the actual error, which turned out to be "Invalid token or user mismatch", fixed by /login. Possible it was a combo of multiple issues, but it does work now

@ZanderAdam's fix worked for me on mac! I checked ~/.claude/debug/, and sure enough had the same "Invalid token or user mismatch" log.

A simple /login did the trick

jesus christ i love but hate this plugin!! lol

For anyone still hitting this on macOS with both Claude Desktop and Claude Code installed — a working workaround is documented in #24935.

TL;DR: The JSON-editing workarounds don't work because the chrome MCP runs in-process and GrowthBook overwrites the flag in memory. Use CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 instead, and disable Desktop's native messaging manifest if you have both apps installed.

Thank you for your report — we are currently in the process of triaging MCP-related issues and this one appears to describe the same problem as #21337. To keep the discussion and any fix in one place, we're consolidating into that issue and closing this one. If you have logs, repro steps, or environment details that aren't already covered in #21337, please add them there — it'll help us track this down faster.

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.