[BUG] MCP tools fail with "Browser extension is not connected" despite /chrome showing Connected

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/20811
2. https://github.com/anthropics/claude-code/issues/20786
3. https://github.com/anthropics/claude-code/issues/20318

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

Similar issue on MacOS (M4/26.2) but the Claude app works just fine with Chrome and Vivaldi. The problem is only in the CLI from iTerm and via the plugin in IntelliJ IDEs.

From claude code:

Chrome native messaging is fundamentally broken on your system for an unknown reason. We've verified:

• ✅ Registry correct
• ✅ Manifest valid JSON
• ✅ Files exist
• ✅ Native host works from cmd.exe
• ❌ Chrome never even attempts to run the batch file

This could be:

1. Windows Defender/antivirus blocking Chrome from spawning processes
2. A Chrome installation issue (Enterprise policies, Store version, etc.)
3. Some Windows security setting

I'm experiencing the same issue. Here are my environment details:

Environment:

• Claude Code version: 2.1.19
• - Chrome version: 144.0.7559.97
• - - OS: macOS 26.2
• - - - Chrome extension: installed and shows "connected" via /chrome command

Behavior:

• /chrome command reports "connected" status
• - All MCP chrome tools fail with "Browser extension is not connected" error
• - - Tried reconnecting extension - no change
• - - - All chrome MCP tools fail with the same error

This appears to be a widespread issue affecting multiple users across different platforms. Consolidating here to help with prioritization.

+1 Experiencing this same issue.

Important finding: The browser extension works perfectly on v2.1.19 but fails on v2.1.25. This suggests a regression was introduced between these versions.

Workaround: Downgrade to v2.1.19:

npm install -g @anthropic-ai/claude-code@2.1.19

See my detailed report with version comparison: #21825

Same issue on Mac os m1 pro using Cowork
Claude 1.1.2102 (c5675a)
Chrome 144.0.7559.133

Extension looks connected from Claude, and working in Chrome but the communication is broken

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:

Native host creates:  \\.\pipe\claude-mcp-browser-bridge-Dennis Bosma
MCP client expects:   \\.\pipe\claude-mcp-browser-bridge-DennisBosma
                                                          ^^^^ sanitized

This causes MCP tools to fail with "Browser extension is not connected" even when:

• ✅ Extension shows "Enabled, Installed"
• ✅ Chrome native messaging works (ping/status)
• ❌ MCP tool calls timeout (pipe name mismatch)

Why This Matters

This bug persists EVEN AFTER applying existing workarounds:

• ✅ Node.js instead of Bun → fixes stdin crash
• ✅ Patched getSocketPaths() → fixes pipe discovery
• ❌ Username space bug still blocks connection

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:

const username = os.userInfo().username.replace(/\s+/g, '');
const pipeName = `\\\\.\\pipe\\claude-mcp-browser-bridge-${username}`;

Test Evidence

Direct pipe connection test confirms the pipe with space exists:

const net = require('net');
const pipe = '\\\\.\\pipe\\claude-mcp-browser-bridge-Dennis Bosma';
net.createConnection(pipe).on('connect', () => console.log('✓ Pipe exists!'));
// Result: ✓ Pipe exists!

But MCP tools search for the sanitized version (without space) and fail.

Affected Users

• ~30-50% of Windows users (default Windows setup creates usernames with spaces)
• Corporate accounts: "FirstName LastName" format
• Personal PCs: Full names entered during setup
• Domain-joined: AD format "First Last"

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.

Update: Published the complete self-healing fix (including username space handling) as open-source: bosmadev/claude — scripts/fix-chrome-native-host.py

SessionStart hook auto-repairs all 3 Windows Chrome bugs on every launch. See #23828 for full details.

Accessing the claude in chrome extension via claude code was just working for me a few days ago when I first tried it out but stopped working yesterday. Accessing the extension from Claude Desktop still works though.

Keep getting this:

The Claude browser extension isn't currently connected. To use Chrome browser automation, you'll need to:
1. Install the Claude browser extension from https://claude ai/chrome
2. Make sure you're logged into claude. ai with the same account as Claude Code
3. If this is your first time, you may need to restart Chrome after installation

CC: 2.1.39
MacOS: 26.2
Chrome: 145.0.7632.46

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.