Claude in Chrome: MCP client not discovering local socket on Linux despite working native host

Description

The "Claude in Chrome" browser extension's native messaging host runs correctly and creates a working Unix domain socket, but the Claude Code MCP client (mcp__claude-in-chrome__tabs_context_mcp) consistently returns "Browser extension is not connected."

This is a socket discovery issue — the native host is running, the socket is listening, and direct connections to the socket succeed via Node.js net.createConnection(). The MCP client within the Claude Code session is not finding or connecting to it.

Environment

• Claude Code: 2.1.97
• Claude in Chrome extension: 1.0.66 (Beta)
• Chrome: 146.0.7680.177
• OS: Linux 6.17.0-20-generic x86_64 (Ubuntu)
• Node.js: v24.6.0
• Auth method: claude.ai subscription (Max plan, email: verified same on both CLI and browser)
• Interface: Claude Code CLI (terminal)

Diagnostic Evidence

1. Native messaging host config is correct

// ~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json
{
  "name": "com.anthropic.claude_code_browser_extension",
  "description": "Claude Code Browser Extension Native Host",
  "path": "/home/dev/.claude/chrome/chrome-native-host",
  "type": "stdio",
  "allowed_origins": ["chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/"]
}

2. Native host wrapper script is correct

#!/bin/sh
exec "/home/dev/.nvm/versions/node/v24.6.0/bin/node" \
  "/home/dev/.nvm/versions/node/v24.6.0/lib/node_modules/@anthropic-ai/claude-code/cli.js" \
  --chrome-native-host

3. Native host process runs and creates socket

$ ps aux | grep chrome-native-host
dev  24616  .../cli.js --chrome-native-host

$ ls -la /tmp/claude-mcp-browser-bridge-dev/
srw------- 1 dev dev 0 Apr 9 20:30 24616.sock

$ ss -xlp | grep claude
u_str LISTEN /tmp/claude-mcp-browser-bridge-dev/24616.sock users:(("MainThread",pid=24616,fd=21))

4. Direct socket connection SUCCEEDS

const net = require('net');
const sock = net.createConnection('/tmp/claude-mcp-browser-bridge-dev/24616.sock', () => {
  console.log('Connected to socket successfully!'); // ✅ Works
});

5. MCP tool always FAILS

mcp__claude-in-chrome__tabs_context_mcp({createIfEmpty: true})
→ "Browser extension is not connected."

6. Feature flags — all bridge flags disabled, still fails

"tengu_copper_bridge": false,
"tengu_bridge_repl_v2": false,
"tengu_ccr_bridge": false,
"tengu_ccr_bridge_multi_session": false

7. Auth is correct (not API key)

{ "loggedIn": true, "authMethod": "claude.ai", "subscriptionType": "max" }

No ANTHROPIC_API_KEY environment variable set.

Troubleshooting Attempted (ALL failed)

• Restarted Chrome multiple times
• Restarted entire system
• Toggled extension off/on
• Completely removed and reinstalled extension
• Killed orphaned chrome-native-host processes, cleaned sockets, let Chrome respawn fresh ones
• Clicked extension icon to wake service worker
• Verified no console errors in extension service worker
• Verified accounts match between CLI and browser
• Updated Claude Code to latest (2.1.97)
• Set tengu_copper_bridge to false (workaround from #35675)
• Disabled all bridge-related feature flags
• Started Claude Code with --chrome flag
• Used wrapper script to set flags before launch
• Verified socket is connectable directly via Node.js net module

Analysis

The native host, socket, config, and extension are all working correctly. The bug is in the Claude Code MCP client's socket discovery on Linux — it either isn't looking in /tmp/claude-mcp-browser-bridge-{username}/ or the internal handshake/protocol is failing silently.

This appears to be a Linux-specific variant. Most existing reports (#20298, #35675, #40758, #41879, #42344) are macOS and have workarounds that don't apply here.

Related Issues

• #20298 — Chrome not connecting (macOS, native host path)
• #35675 — Not connected despite correct setup (macOS, tengu_copper_bridge flag)
• #40758 — Chrome extension not connecting (macOS)
• #41879 — Not connected despite native messaging working (macOS)
• #42344 — Not connected despite successful pairing (macOS)