Claude in Chrome: native host healthy but CLI never dials into bridge socket (Ubuntu 26.04)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (see Related Issues below for close matches — filing separately since environment/repro differs)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

This is a regression — the integration was working correctly yesterday and broke without any intentional change on my end (no manual extension reinstall, no CLI upgrade I initiated, no config edits).

Claude Code CLI's --chrome MCP integration never connects to the Chrome native-messaging bridge socket, even though the native host process spawns correctly, the socket is created with correct permissions, and the manifest is correctly registered. All mcp__claude-in-chrome__* tool calls fail with "Browser extension is not connected."

This has been reproduced across 3 separate fresh native-host generations (via full Chrome quit/relaunch, including with tab groups cleared), ruling out staleness. Each time, the socket is confirmed live via lsof, but shows zero client connections — the CLI process never attempts to dial in.

Environment

• OS: Ubuntu 26.04 LTS ("Resolute")
• Chrome: 151.0.7922.137
• Claude in Chrome extension: 1.0.85 (fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Claude Code: 2.1.232
• CLAUDE_CONFIG_DIR: custom, set to /home/sol/work/.claude (ruled out as cause — see below)

Diagnostics Performed / Ruled Out

1. Claude Desktop conflict (the most common known cause, per #45318/#65682/#24784): Ruled out. Claude Desktop is not installed on this machine — confirmed via ls /opt/Claude*, which claude-desktop, dpkg -l | grep claude, find / -iname "*claude*.desktop", and ps aux all returning empty.

1. Native messaging manifest correctness: Confirmed present and correct at ~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json, pointing to the correct wrapper path and matching the installed extension ID. No competing com.anthropic.claude_browser_extension.json (Desktop's manifest name) exists on this system.

1. Custom CLAUDE_CONFIG_DIR path mismatch: Investigated as a possible cause since this session uses a non-default config dir (/home/sol/work/.claude instead of ~/.claude). Ruled out: no stray ~/.claude/chrome/ directory exists at the default path (would indicate a dual-location split), and the bridge socket path (/tmp/claude-mcp-browser-bridge-$USER/<PID>.sock) is keyed by username, not by CLAUDE_CONFIG_DIR, so both native host and CLI should agree on it regardless of config dir location.

1. Socket/native-host health: Confirmed healthy across 3 fresh generations (PIDs observed: 9847, then two subsequent regenerations including PID 19823). Each time:

• Native host process is running as a direct child of Chrome
• Socket exists at /tmp/claude-mcp-browser-bridge-sol/<PID>.sock
• Socket permissions correct
• lsof on the socket shows only the native host itself — no client ever attaches
• CLI process shows zero dial/connection attempts over a 4-second polling window per generation

Steps to Reproduce

1. Start a claude --chrome (or equivalent Chrome-enabled) CLI session on Ubuntu 26.04 with Claude Code 2.1.232 and Claude in Chrome extension 1.0.85 installed and signed in (side panel works fine standalone).
2. Attempt any mcp__claude-in-chrome__* tool call (e.g. tabs_context_mcp).
3. Observe: "Browser extension is not connected."
4. Inspect the native host process and socket — both healthy, but lsof shows no CLI-side connection.
5. Fully quit and relaunch Chrome (clearing tab groups) to force a fresh native-host generation. Repeat steps 2–4. Same result, reproduced 3 times.

Expected Behavior

The CLI should connect to the native host's Unix socket shortly after the native host spawns, and mcp__claude-in-chrome__* tools should return live tab/browser data instead of a "not connected" error.

Actual Behavior

Native host and socket are demonstrably healthy and listening, but the CLI never attaches as a client. Failure is consistent across fresh native-host generations, ruling out staleness as the cause.

Related Issues

This appears to match the "healthy socket, zero CLI connections" pattern described in several other open reports, though none of those threads mention a custom CLAUDE_CONFIG_DIR or explicitly rule out Claude Desktop the way this report does:

• #45318 — [Bug] Claude in Chrome: CLI MCP client never connects to bridge socket when Desktop is also installed (this report rules out Desktop entirely, suggesting the second-stage failure described there — CLI never connecting even once Desktop conflict is resolved — may be independent of Desktop)
• #31660 — Chrome extension service worker never initiates native messaging connection (Linux/Xpra)
• #65682 — Claude in Chrome: CLI never connects when Claude Desktop is installed — extension binds only to Desktop's native host
• #36763 — Chrome extension: MCP server never connects to native host socket
• #24784 — Claude in Chrome MCP server fails to connect to native host bridge socket

Additional Notes / Ask

• This is a regression, not a first-time setup issue — Claude in Chrome was working normally on this machine as of yesterday. I did not knowingly change the Chrome extension version, Claude Code version, or any related config in between. If either the extension or CLI auto-updated in the background, that's the most likely trigger and would be useful to confirm on your end (e.g., via version telemetry, if available, for this account/machine).
• Is there a debug flag or verbose logging mode for the CLI's socket-discovery/dial logic? It would help confirm whether the CLI is attempting to locate the socket at all, or failing before that point (e.g., not scanning /tmp/claude-mcp-browser-bridge-$USER/ for some reason specific to this environment).
• Happy to run additional diagnostics (strace on the CLI process during a tool call, packet/IPC tracing, etc.) if that would help narrow this down further.