Claude in Chrome: CLI never connects to native-host bridge socket (macOS, v2.1.121)
Resolved 💬 3 comments Opened Apr 28, 2026 by ppikula Closed May 31, 2026
Environment
- macOS 26.3 (Darwin 25.3.0 arm64)
- Claude Code: 2.1.121
- Chrome extension: 1.0.69 (ID
fcoeoabgfenejglbffodgkkbkcdhcgfn) - Google Chrome: 148.0.7778.56
- Both Claude Desktop and Claude Code installed
Symptom
Every mcp__claude-in-chrome__* tool call returns:
Browser extension is not connected. Please ensure the Claude browser extension is installed and running...
What works
- Chrome → native host: when the extension wakes, Chrome successfully spawns
claude.exe --chrome-native-host, which binds to/tmp/claude-mcp-browser-bridge-$USER/<pid>.sock(mode 0600, dir 0700). - The disconnect message correctly indicates the bridge isn't connected.
What doesn't work
- The
claude --chromeCLI session never opens a client connection to the bridge socket.lsof -p <claude-pid>shows no fd for/tmp/claude-mcp-browser-bridge-*.
Steps tried (all clean, none fixed it)
- Renamed Claude Desktop's
com.anthropic.claude_browser_extension.json→.disabled(per a Reddit fix that worked for others). - Fully quit & reopened Chrome.
- Uninstalled and reinstalled the Chrome extension.
- Updated Claude Code 2.1.119 → 2.1.121.
- Killed the native-host process so Chrome respawns it on the new binary; cleaned stale
.sockfiles. - Started multiple fresh
claude --chromesessions after each step. - Removed
com.apple.quarantinexattr from the bridge directory. - Verified socket dir mode 0700, socket mode 0600.
Notes
- Result is the same whether the Desktop host config is enabled or disabled.
- Native host and CLI are both running the same binary path / version 2.1.121, so it isn't a version skew.
- Happy to provide debug logs if there's a flag/path that surfaces the CLI's bridge-connection attempts (
--debugdoesn't appear to surface them).
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗