claude-code - 💡(How to fix) Fix [BUG] claude --chrome reports "extension not connected" despite a healthy native messaging host [1 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Every browser command from claude --chrome returns "The Claude browser extension isn't connected." The Chrome extension is installed (v1.0.69, freshly reinstalled), enabled, signed in, and its own side-panel chat works correctly. The native messaging host is healthy: Chrome successfully spawns the host process when the extension activates, and it listens on its Unix socket. The failure is on the Claude Code session side — claude --chrome never opens a connection to the existing bridge socket.

What Should Happen?

Claude Code connects to the bridge socket exposed by the native messaging host and drives the browser via the extension. Browser commands like "open this URL" or "tell me what's on the page" should execute and return results.

Error Messages/Logs

The Claude browser extension isn't connected. Please ensure the Claude Chrome extension is installed (https://claude.ai/chrome), running, and logged in with the same account as Claude Code — you may need to restart Chrome.

Steps to Reproduce

1. Install Claude Code 2.1.123 on macOS.
2. Install the "Claude in Chrome" extension v1.0.69 from the Chrome Web Store; sign in.
3. Confirm the extension's own side-panel chat works (proves extension is healthy).
4. In a terminal: claude --chrome
5. Ask: Open code.claude.com/docs and tell me the page title
6. Observe the error: "The Claude browser extension isn't connected."
7. Run /chrome → "Reconnect extension" — same error persists. Verified state during failure (all healthy):

• Native host config at ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json points to ~/.claude/chrome/chrome-native-host (which execs the 2.1.123 binary with --chrome-native-host).
• pgrep -lf chrome-native-host shows the host process is alive, parent PID = Chrome.
• lsof /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock shows the host listening, zero clients.
• lsof -p <claude --chrome PID> shows no FD on the bridge socket — the session never tries to connect.
• The claude --chrome session was started 66 seconds AFTER the native host was up and listening, so timing is not the cause.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown (was working in a previous version weeks ago; exact version not recalled)

Claude Code Version

2.1.123 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

I am using Termius terminal.

Environment details:

• macOS Darwin 24.6.0
• Google Chrome 147.0.7727.102
• Claude in Chrome extension version 1.0.69 (clean reinstall)
• Subscription: Claude Max (Anthropic plan)
• Same email signed into both Claude Code and the extension
• Claude desktop app (/Applications/Claude.app) is also installed and bundles its own /Applications/Claude.app/Contents/Helpers/chrome-native-host. It registers under the same native messaging host name (com.anthropic.claude_code_browser_extension) and previously hijacked the Chrome registration. After today's Claude Code 2.1.123 install the config points to Claude Code's wrapper, but the desktop app appears to fight for the same slot whenever it launches. Worth investigating whether Claude Code and Claude desktop should use distinct host names.

Things tried, none of which fixed the symptom:

• Full Chrome quit (Cmd+Q) and relaunch.
• Killing orphaned native-host processes from the desktop app and removing stale sockets in /tmp/claude-mcp-browser-bridge-<user>/.
• Removing and reinstalling the Chrome extension; signing back in.
• Starting a fresh claude --chrome session AFTER the bridge socket was already created and listening.
• Quitting the Claude desktop app entirely.
• Manually re-stamping ~/.claude/chrome/chrome-native-host to point at the 2.1.123 binary.

Observed root cause hypothesis: Claude Code's session-side discovery/handshake to an existing, healthy bridge socket is not happening. The Chrome → extension → native-host half of the bridge is verifiably working end to end.