Claude in Chrome: native-messaging connection never establishes despite fresh host process/socket

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 25, 2026

Description

The Claude in Chrome extension's tabs_context_mcp tool consistently reports "Browser extension is not connected", even after the extension is confirmed logged in with no errors shown in chrome://extensions.

Troubleshooting already tried (no change in outcome)

  1. Confirmed extension shows logged in, no errors button in chrome://extensions.
  2. Reloaded the extension from chrome://extensions — no change.
  3. Fully quit Chrome (Cmd+Q / osascript -e 'quit app "Google Chrome"') and reopened it.

Observation after full restart

A fresh chrome-native-host process spawns on Chrome start, with its own new Unix socket bridge:

/Applications/Claude.app/Contents/Helpers/chrome-native-host chrome-extension://<ext-id>/
socket: /tmp/claude-mcp-browser-bridge-<user>/<pid>.sock

The process is alive, has open stdio pipes to Chrome, and the socket file exists and is singular (no stale duplicates). Despite this, tabs_context_mcp still returns "not connected" immediately after restart.

Additionally, in Chrome's Default/Secure Preferences, the extension's active_bit remains false even right after a full Chrome restart, while has_started_service_worker is true — suggesting the extension's MV3 service worker starts once then goes idle without maintaining/reopening the native-messaging port.

Environment

  • macOS (Darwin 25.5.0)
  • Chrome stable
  • Claude Code CLI

Expected

tabs_context_mcp (or another mcp__claude-in-chrome__* tool call) should succeed once the extension is installed, logged in, and Chrome has been freshly restarted.

Actual

Persistent "Browser extension is not connected" error regardless of restart/reload.

View original on GitHub ↗