Claude in Chrome MCP returns "not connected" despite all plumbing healthy (Claude Desktop on macOS)

Preflight Checklist

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

What's Wrong?

Got it. Here's the bug report — draft it once, you paste it. Then we'll restart Claude Desktop.

---

Bug Report Draft

Title: Claude in Chrome MCP returns "not connected" despite all plumbing healthy (Claude Desktop on macOS)

Body:

````markdown

Summary

The mcp__Claude_in_Chrome__* tools (list_connected_browsers, switch_browser) consistently return "Claude in Chrome is not connected. The Chrome extension isn't reachable right now." — even though every layer of the integration is verifiably alive, the connector is enabled, and the side-panel agent (which uses the same native-messaging bridge) works correctly in the same browser.

Environment

• macOS 25.4.0 (Darwin)
• Claude Desktop: 1.4758.0 (com.anthropic.claudefordesktop)
• Claude Code (CLI bundled inside desktop): 2.1.119 / Agent SDK 0.2.119
• Model: claude-opus-4-7[1m]
• Account: Max plan, single account on both Desktop and Chrome extension
• CLAUDE_CODE_ENTRYPOINT=claude-desktop (CLI launched as a child of Claude Desktop)
• Google Chrome: latest, signed into same Google profile
• Claude in Chrome (Beta) extension v1.0.69, ID fcoeoabgfenejglbffodgkkbkcdhcgfn, signed in as the same Anthropic account

Reproduction

1. Open Claude Desktop, ensure the "Claude in Chrome" connector is Enabled (Settings → Connectors → Claude in Chrome [Beta]).
2. Have Chrome open with the Claude in Chrome (Beta) extension installed and signed in.
3. Confirm side-panel agent works (e.g., ask the side panel to "open a new tab and search Google for hello" — succeeds).
4. From a Claude Code session under the same Desktop instance, call:

• mcp__Claude_in_Chrome__list_connected_browsers → "not connected"
• mcp__Claude_in_Chrome__switch_browser (broadcast pairing) → "not connected" (no popup ever appears in the extension)

1. Retrying multiple times over several minutes does not recover.

Diagnostics gathered

| Check | Result |
|---|---|
| Native-messaging host manifest at ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json | ✅ Present, points to /Applications/Claude.app/Contents/Helpers/chrome-native-host, allowed_origins includes the extension ID |
| Native host binary | ✅ Present, executable, universal Mach-O |
| Native host process | ✅ Running (pgrep finds chrome-native-host chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/) |
| Claude Desktop process tree | ✅ Healthy; this Claude Code CLI is a direct child of Claude.app |
| claude mcp list (local MCP servers) | ✅ Empty as expected — Chrome MCP tools are provided by Claude Desktop, not user-configured |
| Claude Desktop → Settings → Connectors → "Claude in Chrome [Beta]" | ✅ Enabled toggle on |
| Extension Details (chrome://extensions): permissions, native messaging, "On all sites" | ✅ All granted |
| Extension options.html: signed-in email matches account | ✅ Match |
| Side-panel agent in Chrome (same extension, same pipe) | ✅ Works — opens tabs, performs searches |
| Parallel mcp__Control_Chrome__* tools (separate desktop extension) | ✅ Fully functional — list_tabs, get_current_tab, switch_to_tab all succeed against the same Chrome |
| mcp__Claude_in_Chrome__list_connected_browsers | ❌ "not connected" |
| mcp__Claude_in_Chrome__switch_browser | ❌ "not connected" — no pairing prompt appears in extension |

Expected

• list_connected_browsers returns at least one device entry for the running Chrome.
• switch_browser triggers a "Connect" prompt inside the Chrome extension.

Actual

• Both calls return the templated "not connected / often transient" message and never recover.
• The fact that the parallel Control Chrome connector works against the same browser proves the issue is not Chrome, the extension, accounts, permissions, or any user-side configuration — it's specifically the in-app relay between the Claude Code session and the Claude in Chrome MCP service inside Claude Desktop.

Ruled out

• Account mismatch (verified same email across CLI + Desktop + extension)
• Extension not installed / not signed in
• Native messaging host missing or misconfigured
• Connector disabled in Desktop settings
• Site permissions ("Your approved sites" being empty wouldn't explain pairing-discovery failure)

Workaround

Use the Control Chrome desktop extension's mcp__Control_Chrome__* tools instead — they cover tab/navigation/content operations against the same browser and work reliably.

Suggested investigation

• Whether the Claude in Chrome MCP service inside Claude Desktop registers the running Chrome at startup vs on demand, and whether it picks up extensions installed after Desktop launched.
• Whether full Cmd-Q + relaunch of Claude Desktop restores the relay (will test next).

````

---

When you've copied that, quit Claude Desktop with Cmd-Q (this will end this session). After it relaunches and you start a new Claude Code session, paste this transcript link or just say "continuing the chrome connection debug — try list connected browsers first" and we'll resume from there.

What Should Happen?

It should have connected to Chrome

Error Messages/Logs

please see whats wrong session

Steps to Reproduce

please see whats wrong session

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Desktop: 1.4758.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Root cause (identified through socket inspection)

The bridge directory /tmp/claude-mcp-browser-bridge-<username>/ contains a per-PID socket created by chrome-native-host for each connected browser, e.g. /tmp/claude-mcp-browser-bridge-piyushkuchhadiya/1983.sock.

Verified state at time of bug:

• Socket file exists (srw-------, owned by user)
• lsof shows chrome-native-host (PID 1983) has the listening FD open
• No other process has a client FD on the socket — i.e. Claude Desktop's MCP service never connected
• Manual socket.connect() from a one-off Python process succeeds — the socket is accepting connections, so the listener is healthy

Therefore the failure is in Claude Desktop's discovery/connection step, not in the extension or the native host. The most plausible explanation is a one-shot scan at Desktop launch that misses bridge sockets created later (e.g. when Chrome / the extension starts after Desktop, or when the native host respawns). A directory watcher (FSEvents on macOS) on /tmp/claude-mcp-browser-bridge-<username>/ would fix this.

Workaround

Quit and relaunch Claude Desktop after Chrome+extension are running. (Will verify and update.)