claude-code - 💡(How to fix) Fix Claude-in-Chrome MCP bridge fails on Windows: framing protocol mismatch between MCP client and native host

Summary

On Windows, every mcp__claude-in-chrome__* tool call returns "Browser extension is not connected". Through end-to-end tracing of the Chrome Native Messaging protocol and the local IPC pipe, the root cause is a framing protocol mismatch internal to claude.exe: the MCP client sends raw JSON-RPC, but the native host's named-pipe server expects each message to be prefixed by a 4-byte UInt32-LE length. The server reads the first four bytes of {"jsonrpc":"2.0",...} as a 1.9 GB "message length", logs Invalid message length, destroys the client socket, and tells Chrome mcp_disconnected.

This is a Claude Code bug, not a Chrome, extension, or Bun runtime issue.

Environment

• OS: Windows 11 Pro 10.0.26200
• Chrome: 148.0.7778.97 (Official Build) (64-bit), Stable
• Claude Code: 2.1.139 (native build, ~/.local/bin/claude.exe)
• Claude in Chrome extension: fcoeoabgfenejglbffodgkkbkcdhcgfn version 1.0.70_0
• Node.js (for diagnostic tooling): v22.16.0

Steps to Reproduce

1. Install Claude Code 2.1.139 and the Claude Chrome extension on Windows.
2. Be signed in to claude.ai in both.
3. From a Claude Code session, invoke any mcp__claude-in-chrome__* tool (e.g. tabs_context_mcp).

Observed Behavior

Tool returns:

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

Diagnostic Setup

I replaced ~/.claude/chrome/chrome-native-host.bat with a Node.js MITM wrapper that:

• Spawns claude.exe --chrome-native-host as a child
• Forwards stdin/stdout bytes unchanged in both directions
• Logs every Chrome ↔ native-host message (with length-prefix parsing), plus the child's stderr

This let me capture exactly what happens when Chrome's extension spawns the native host and what the host does next. I also wrote a small Node.js test that connects directly to \\.\pipe\claude-mcp-browser-bridge-<user> to verify the pipe layer in isolation.

Captured Trace

==== WRAPPER START pid=20756 ====
Spawning: C:\Users\USER\.local\bin\claude.exe --chrome-native-host
Child spawned, pid=21788
CHROME→CLAUDE [15 bytes] {"type":"ping"}
STDERR: [Claude Chrome Native Host] Initializing...
STDERR: [Claude Chrome Native Host] Creating socket listener:
\\.\pipe\claude-mcp-browser-bridge-USER
STDERR: [Claude Chrome Native Host] Socket server listening for connections
STDERR: [Claude Chrome Native Host] Handling Chrome message type: ping
STDERR: [Claude Chrome Native Host] Responding to ping
CLAUDE→CHROME [41 bytes] {"type":"pong","timestamp":1778554589426}
CHROME→CLAUDE [21 bytes] {"type":"get_status"}
STDERR: [Claude Chrome Native Host] Handling Chrome message type: get_status
CLAUDE→CHROME [56 bytes]
{"type":"status_response","native_host_version":"1.0.0"}

# ... time passes; user invokes a tool from Claude Code ...

STDERR: [Claude Chrome Native Host] MCP client 1 connected. Total clients: 1
CLAUDE→CHROME [24 bytes] {"type":"mcp_connected"}
STDERR: [Claude Chrome Native Host] Invalid message length from MCP client 1:
 1936335483
STDERR: [Claude Chrome Native Host] MCP client 1 disconnected. Remaining
clients: 0
CLAUDE→CHROME [27 bytes] {"type":"mcp_disconnected"}

So the Chrome ↔ native-host channel is healthy. The named pipe is created. The MCP client successfully reaches it and is accepted. Then the very first read of message bytes is rejected as "Invalid message length: 1936335483", and the server destroys the socket.

Root Cause

Decoded as a little-endian UInt32, 1936335483 is 0x736F6E7B, the four bytes {"js — the first four characters of {"jsonrpc":"2.0",...}.

The native host's handleMcpClient reads incoming data with buffer.readUInt32LE(0) and treats it as a length prefix:

H.on("data",(K)=>{
  $.buffer = Buffer.concat([$.buffer, K]);
  while ($.buffer.length >= 4) {
    let _ = $.buffer.readUInt32LE(0);
    if (_===0 || _>VUq) {
      tj(`Invalid message length from MCP client ${q}: ${_}`),
      H.destroy();
      return;
    }
    if ($.buffer.length < 4 + _) break;
    // ... parse JSON from buffer.slice(4, 4 + _) ...
  }
});

The client side, however, is writing the JSON payload without the 4-byte length prefix. The two halves of the same binary are speaking different framing protocols.

Independent Confirmation via Node.js

I wrote a minimal Node script that connects to the named pipe and sends raw JSON.stringify(rpcMessage) + "\n":

$ node test-pipe-connect.js
Connecting to: \\.\pipe\claude-mcp-browser-bridge-USER
CONNECTED in 1ms
Sending a test MCP message...
Socket closed

The wrapper log shows the same "Invalid message length: 1936335483" for the Node client. This rules out anything Claude-Code-MCP-client-specific: any client that sends bare JSON-RPC hits the same wall. The framing on the wire is the issue.

Why client-side workarounds didn't work

Before tracing the protocol I tried, in order:

1. Renaming Claude Desktop's native messaging manifest to .json.disabled (the macOS-style workaround documented for the Feb-2026 issue).
2. Killing cowork-svc.exe (Claude Desktop's background service).
3. Restarting Chrome.
4. Reloading the extension.
5. Downgrading Claude Code to 2.1.138 (newest cached version).

None of these changed the outcome, because they all addressed a different layer than the one that's broken. The Feb-2026 getSocketPaths() regression that returned Unix-style paths on Windows is fixed in 2.1.139 — sH7() correctly returns [\\.\pipe\claude-mcp-browser-bridge-USER] on win32 — so the discovery side is healthy. The break is one layer deeper, in the framing of bytes on the established pipe connection.

Suggested Fix

Either:

1. Update the server to accept raw JSON-RPC framing (e.g. newline-delimited or Content-Length headers) — matching whatever the MCP client now emits.
2. Update the client to prepend each outgoing message with a UInt32-LE length prefix before writing to the pipe — matching what the server already expects.

Option 2 is more in keeping with how Chrome's own Native Messaging protocol frames messages (4-byte length prefix), which is presumably why the server was written this way.

A binary patch on the user's side is feasible but fragile across versions. A first-party fix is needed.

Reproducibility

100% on this machine. Diagnostic wrapper script + named-pipe test script available on request — happy to attach them or open a PR.