Claude in Chrome: MCP reports "Browser extension is not connected" while the native-host bridge socket is alive and idle

Summary

All mcp__claude-in-chrome__* tools fail with Browser extension is not connected, but every component of the local bridge is verifiably healthy. The native messaging host is running, spawned by Chrome, with its stdio pipes to the extension open and its unix socket listening. Claude Code never opens a connection to that socket — not even a transient one.

The failure is on the Claude Code client side of the bridge, not in the extension, the native messaging setup, or Chrome.

Environment

| | |
|---|---|
| Claude Code | 2.1.223 |
| Chrome | 150.0.7871.189 (stable, macOS) |
| Claude extension | 1.0.84 (fcoeoabgfenejglbffodgkkbkcdhcgfn) |
| OS | macOS 15 (Darwin 24.6.0), Apple silicon |
| Chrome profile | single profile (Default) |
| Launch | claude -c --permission-mode auto in iTerm2 |

Reproduction

Call any claude-in-chrome tool, e.g. list_connected_browsers or tabs_context_mcp. Both return, instantly:

Browser extension is not connected. Please ensure the Claude browser extension is
installed and running (https://claude.ai/chrome), and that you are logged into
claude.ai with the same account as Claude Code. ...

The standard remedies in that message (reinstall, re-login, restart Chrome) do not apply — see below.

What I verified

Everything in the documented chain checks out:

1. Extension installed and running. v1.0.84 in the only Chrome profile.

1. Native messaging manifest correct.

~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json
``json
{
"name": "com.anthropic.claude_code_browser_extension",
"path": "/Users/<user>/.claude/chrome/chrome-native-host",
"type": "stdio",
"allowed_origins": ["chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/"]
}
`
allowed_origins` matches the installed extension ID.

1. Wrapper script resolves to a real, executable, version-matched binary.

``sh
exec "/Users/<user>/.local/share/claude/versions/2.1.223" --chrome-native-host
`
2.1.223` exists, is executable, and matches the running CLI.

1. The native host works standalone. Driving it directly over stdio with native-messaging framing (4-byte LE length prefix):

``
-> {"type":"ping"}
<- {"type":"pong","timestamp":1785998052412}
`
stderr:
`
[Claude Chrome Native Host] Initializing...
[Claude Chrome Native Host] Creating socket listener: /tmp/claude-mcp-browser-bridge-<user>/81186.sock
[Claude Chrome Native Host] Socket server listening for connections
[Claude Chrome Native Host] Socket permissions set to 0600
[Claude Chrome Native Host] Handling Chrome message type: ping
[Claude Chrome Native Host] Responding to ping
``

1. Chrome actually spawned the native host, and it is alive.

``
$ ps -p 55522 -o pid=,ppid=,lstart=,command=
55522 68343 Thu Aug 6 14:19:06 2026 /Users/<user>/.local/share/claude/versions/2.1.223 --chrome-native-host
`
PPID 68343` is the Chrome main process. So the extension side is live and native messaging is functioning.

1. The bridge socket is listening, and the stdio pipes to Chrome are open.

``
$ lsof -p 55522
2.1.223 55522 <user> 0 PIPE 0xde77f51346dc3522 16384 ->0x59d574d20a3e2d8a
2.1.223 55522 <user> 1 PIPE 0x5e31b141dbfa455a 16384 ->0xf772100b6a004d3e
2.1.223 55522 <user> 4 PIPE 0x5e31b141dbfa455a 16384 ->0xf772100b6a004d3e
2.1.223 55522 <user> 6u unix 0x425d0adac89c213f 0t0 /tmp/claude-mcp-browser-bridge-<user>/55522.sock
``
fd 6 is the listening socket. There is no accepted connection.

1. The socket accepts connections and responds. Connecting manually and sending a length-prefixed JSON message gets a reply from the native host:

``
-> {"jsonrpc":"2.0","id":1,"method":"initialize",...}
<- {"result":{"content":"Unknown method: initialize"}}
``
(Expected — it isn't raw MCP — but it proves the socket is functional and the process is responsive.)

1. Ordering is correct. The socket was created at 14:19:06; the Claude Code CLI (PID 78450) started at 14:32:36. The socket already existed when Claude Code started, so this is not a startup race.

1. Path derivation is consistent. /tmp/claude-mcp-browser-bridge-<user>/ is the only bridge directory on the system. Nothing under $TMPDIR (/var/folders/.../T/). Both sides hardcode /tmp.

1. Claude Code never connects — confirmed under live sampling. I polled lsof -p 55522 every 150ms for 40s (78 samples) while issuing two MCP tool calls (list_connected_browsers, tabs_context_mcp). Across the whole window exactly 4 distinct entries were ever observed — the 4 baseline fds above. No accepted connection ever appeared. Both calls returned the error instantly, with no latency consistent with socket I/O.

Caveat: at 150ms granularity a sub-150ms connect/close could in principle be missed. The instant-return behaviour argues against that.

Analysis

The extension → native host → listening socket half of the bridge is fully operational. The Claude Code → socket half never happens. Claude Code appears to fail an earlier check and short-circuit to the "not connected" error without attempting the unix socket at /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock.

The error message sends users toward reinstalling the extension, re-checking their claude.ai login, and restarting Chrome — none of which are the problem here, which made this quite hard to diagnose.

Suggestions

• Surface the actual reason for the "not connected" verdict — e.g. which discovery step failed, which directory was scanned, whether a connect was attempted and how it failed. Right now the message is a dead end when the cause isn't one of the three suggested ones.
• A debug/verbose flag that logs bridge discovery and connection attempts would make this self-serviceable.

Happy to run further diagnostics on this machine — the broken state is currently reproducible and I have not restarted anything.