Claude in Chrome: CLI never connects to native host socket (macOS)

Resolved 💬 3 comments Opened Mar 15, 2026 by dzungnht-ui Closed Apr 14, 2026

Bug Description

Claude in Chrome (Beta) tools always return "Browser extension is not connected" despite the extension being properly installed, the native messaging host running, and the socket being accessible.

Environment

  • Claude Code: 2.1.76 (native install)
  • Claude Desktop App: 1.1.6041 (also installed)
  • OS: macOS Darwin 25.3.0 (Apple Silicon)
  • Chrome: 145.0.7632.160
  • Extension: Claude v1.0.61 (ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)
  • Auth: claude.ai Max subscription, logged in both CLI and Chrome

Symptoms

  • mcp__claude-in-chrome__tabs_context_mcp always returns "Browser extension is not connected"
  • Happens with claude --chrome, claude --chrome --dangerously-skip-permissions, and CLAUDE_CODE_ENABLE_CFC=1
  • Happens in fresh sessions after Chrome restart

Debugging Findings

What works:

  • Extension is installed and service worker is active (verified via CDP)
  • Native messaging host starts and creates socket at /tmp/claude-mcp-browser-bridge-{user}/{pid}.sock
  • Socket accepts connections (verified with net.createConnection() in Node.js)
  • Socket directory permissions are correct (0700, owned by user)
  • claudeAiOauth token exists in keychain
  • cachedChromeExtensionInstalled: true in config
  • claudeInChromeDefaultEnabled: true in config
  • User is logged into claude.ai in Chrome (sessionKey cookie present)

What fails:

  • No Claude Code CLI process ever connects to the bridge socket. Verified via lsof — the socket only has the native host listening, zero CLI clients connected.
  • The getSocketPaths() function (jK7) correctly resolves socket paths (scans /tmp/claude-mcp-browser-bridge-{user}/ and finds .sock files)
  • The validateSocketSecurity() checks should pass (directory mode 448/0o700, correct ownership)
  • ensureConnected()refreshClients() path exists in code but never results in a connection

Additional complication:

  • Claude Desktop App installs a competing native messaging host (com.anthropic.claude_browser_extension) that uses /Applications/Claude.app/Contents/Helpers/chrome-native-host
  • Claude Code CLI installs its own (com.anthropic.claude_code_browser_extension) using ~/.claude/chrome/chrome-native-host
  • Chrome only invokes the Desktop App's host (tested by checking running processes)
  • Disabling the Desktop host and using only the CLI host did not fix the issue — CLI still never connects to the socket

Protocol test:

Messages sent to the socket via 4-byte LE length prefix protocol are relayed to Chrome extension and responses come back (e.g., {"result":{"content":"Unknown method: initialize"}}), confirming the relay pipeline works.

Steps to Reproduce

  1. Install Claude Code 2.1.76 and Claude Desktop App on macOS
  2. Install Claude Chrome extension from chrome.ai/chrome
  3. Log into claude.ai in Chrome
  4. Run claude --chrome
  5. Ask Claude to use any mcp__claude-in-chrome__* tool
  6. Always returns "Browser extension is not connected"

Expected Behavior

CLI should connect to the native host socket and relay tool calls to the Chrome extension.

Workaround

None found. The Playwright MCP server (@playwright/mcp) can be used as an alternative for browser automation, but lacks the Chrome extension integration features.

View original on GitHub ↗

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