Claude in Chrome: MCP client never connects to native host bridge socket on Linux

Resolved 💬 2 comments Opened Mar 31, 2026 by OndrejBudicek Closed May 6, 2026

Description

Claude in Chrome integration fails with "Browser extension is not connected" on Linux despite all components being healthy. The MCP client inside Claude Code never establishes a connection to the native host's Unix socket.

This was working ~1 month ago and stopped after updates.

Environment

  • OS: Ubuntu 22.04.5 LTS (kernel 6.8.0-106-generic)
  • Chrome: 146.0.7680.164
  • Claude Code: 2.1.87
  • Claude in Chrome extension: 1.0.64
  • Auth: claude.ai OAuth, Max plan

Steps to Reproduce

  1. Install Claude in Chrome extension from Chrome Web Store
  2. Log in with the same account in both CLI and extension
  3. Run claude --chrome
  4. Ask Claude to interact with Chrome
  5. Error: "Browser extension is not connected"

Diagnostic Results

Every component in the chain works individually — the problem is specifically that the Claude Code MCP client never connects to the bridge socket.

✅ Native host runs correctly (started by Chrome)

$ pgrep -af "chrome-native-host"
132407 /home/user/.local/share/claude/versions/2.1.87 --chrome-native-host

$ ps -o pid,ppid,comm -p 132407
  PID  PPID COMMAND
132407 121537 2.1.87    # parent is chrome

✅ Socket exists and listens

$ ss -xlp | grep bridge
u_str LISTEN /tmp/claude-mcp-browser-bridge-user/132407.sock

$ stat /tmp/claude-mcp-browser-bridge-user/
Access: (0700/drwx------) Uid: (1000/user)

$ stat /tmp/claude-mcp-browser-bridge-user/132407.sock
Access: (0600/srw-------) Uid: (1000/user)

✅ Native messaging protocol works

# Sending ping via Chrome native messaging protocol (4-byte length prefix + JSON)
send({type: "ping"})        → {type: "pong", timestamp: ...}
send({type: "get_status"})  → {type: "status_response", native_host_version: "1.0.0"}

✅ Tool execution through socket works

# Connecting to Unix socket with 4-byte length prefix protocol
send({method: "execute_tool", params: {tool: "tabs_context_mcp", args: {}}})
→ {result: {content: [{type: "text", text: "No MCP tab groups found..."}]}}

This proves the full chain works: socket → native host → Chrome extension → response.

❌ Claude Code MCP client never connects

Using lsof and ss during a claude --chrome session:

$ lsof /tmp/claude-mcp-browser-bridge-user/132407.sock
COMMAND  PID USER  FD TYPE  NODE NAME
2.1.87 132407 user 13u unix  ... /tmp/.../132407.sock type=STREAM (LISTEN only, no connections)

$ ss -xp | grep bridge
# Only the LISTEN entry — zero established connections

The MCP server process (--claude-in-chrome-mcp) has no socket file descriptors beyond stdin/stdout pipes:

$ ls -la /proc/<mcp_pid>/fd/
0 -> pipe:[...]    # stdin
1 -> /dev/null     # stdout (redirected)
2 -> /dev/null     # stderr
3-9 -> /dev/urandom, eventpoll, timerfd, eventfd
# No Unix socket FD

Analysis of binary code

Decompiling the binary shows the connection flow exists:

  • PvK() enumerates .sock files in /tmp/claude-mcp-browser-bridge-{username}/
  • KBq pool manager calls refreshClients()ensureConnected() for each socket
  • fxq.connect() calls validateSocketSecurity() then createConnection()
  • validateSocketSecurity() checks dir permissions (0700) and socket permissions (0600)

All security checks should pass. But strace and lsof confirm the connect syscall is never made. Since Claude Code uses Bun runtime (which uses io_uring on Linux), strace may not capture all syscalls — but the absence of any socket FD in /proc/<pid>/fd/ confirms no connection is ever established.

Expected Behavior

Claude Code should connect to the native host bridge socket and forward tool calls to the Chrome extension.

Actual Behavior

The MCP server starts and reports "connected" in /mcp, but never establishes a Unix socket connection to the native host bridge. All chrome tool calls return "Browser extension is not connected."

Workaround

None found. Manual socket communication with the correct protocol (4-byte length prefix + JSON execute_tool) works perfectly, confirming the issue is isolated to the MCP client's socket connection logic.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗