[BUG] Claude Desktop (Cowork) — list_connected_browsers returns "not connected" for own-account Chrome despite in-browser side panel working

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?

Summary

mcp__Claude_in_Chrome__list_connected_browsers from a Cowork session always returns "Claude in Chrome is not connected", even though the Claude in Chrome extension on the same machine is signed in to the same account and the in-browser side panel works fully. The break is isolated to the relay-side browser-discovery layer that lets Cowork sessions find their account's connected Chrome browsers — not the extension, not local IPC, not the account toggle.

Environment

| Field | Value |
|---|---|
| OS | Windows 10 |
| Claude Desktop | Microsoft Store / MSIX-packaged build, installed under C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ |
| Cowork tools available | Yes — mcp__Claude_in_Chrome__* callable; not a missing-tool issue |
| Browser | Google Chrome (latest stable), single profile |
| Extension | Claude in Chrome (Beta) v1.0.70, ID fcoeoabgfenejglbffodgkkbkcdhcgfn, signed in, enabled, "On all sites" |
| Account | Single Anthropic account (same email signed in to Desktop, claude.ai web, and the extension) |
| Settings → Features → "Claude in Chrome" | Toggled ON |
| Side panel inside Chrome | Works fully — model selector loads, chat input works |
| mcp__Claude_in_Chrome__list_connected_browsers from Cowork | Always returns "not connected" |
| Started failing | Approximately 2026-05-10 (~3 days ago). Last confirmed-working Chrome-driven Cowork session: 2026-05-09 |
| Duration | Persistent — not transient — across multiple days |

Steps to reproduce

1. Sign in to Claude Desktop, Claude in Chrome extension, and claude.ai web with the same Anthropic account.
2. Verify Settings → Features → "Claude in Chrome" is ON.
3. Verify extension popup shows the side panel and model selector loads correctly (proves extension ↔ Anthropic cloud is healthy).
4. In a Cowork chat, invoke mcp__Claude_in_Chrome__list_connected_browsers.
5. Observed: "⚠️ Claude in Chrome is not connected".
6. Expected: the locally-signed-in Chrome browser appears in the list, allowing Cowork to drive it.

What I have already tried (none resolved the Cowork-side issue)

• Reloaded the extension from chrome://extensions.
• Signed out of the extension and signed back in.
• Full Chrome process restart (killed all chrome.exe processes in Task Manager).
• Full Claude Desktop restart (killed all Claude.exe, chrome-native-host.exe, and helpers under \Claude_pzs8sxrjxfjjc\).
• Clean uninstall and reinstall of the extension from the Chrome Web Store + fresh sign-in.
• Verified extension permissions: "On all sites", service worker alive.
• Verified chrome-native-host.exe is running (single persistent instance) and binary is present and recent.
• Verified manifest JSON is present at …\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json with the correct extension ID allowlisted.
• Discovered the Chrome native-messaging-host registry entry was missing on initial diagnosis. Manually created HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension pointing at the manifest. Verified via reg query. Restarted Chrome and Claude Desktop. Cowork integration still does not work, confirming the missing registry entry was a separate (latent) bug and not the root cause of the Cowork issue.
• Started a fresh Cowork chat — same result.

Diagnostic evidence

• DevTools service-worker console for the extension shows zero errors and zero logs during Cowork's list_connected_browsers calls — the extension is never being asked to advertise itself to the Cowork relay.
• chrome-native-host.exe running, PID confirmed in Task Manager.
• 9 claude.exe processes running (normal for MSIX build).
• In-browser side panel chat works → extension ↔ Anthropic cloud is healthy.
• Cowork ↔ Anthropic cloud is healthy (this session is functioning; all non-Chrome tools work).

Bugs identified during diagnosis

1. Primary (still unresolved): Cowork session cannot discover its own account's signed-in Chrome via list_connected_browsers. Likely a server-side relay browser-discovery / account-binding issue.

1. Secondary (mitigated by manual workaround): The MSIX installer for Claude Desktop does not create the Chrome native-messaging-host registry entry under HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension, even though the manifest JSON and chrome-native-host.exe are both placed correctly inside the MSIX package directory. This affects any user attempting to use the connector for the first time after MSIX install. Filing as a separate sub-bug.

Hypothesis

The break is in Anthropic's relay-side browser-discovery layer that lets Cowork sessions find their account's connected Chrome extension instances. The extension successfully registers with Anthropic's cloud (proven by the side panel working). What appears not to happen is the cross-session announcement that lets a separate Cowork session, signed in to the same account, discover that browser as an available client.

Final post-reboot verification — every local cause ruled out

After all the steps above, performed a full Windows reboot and verified every component was healthy post-boot:

• VM service for Cowork: starts cleanly, no error banner.
• Chrome: running with normal tab open.
• Extension: installed, signed in as rajesh@sbuco.in, side panel functional.
• chrome-native-host.exe: spawned fresh post-reboot.
• Registry entry: present and pointing to the manifest.
• Manifest JSON: present at the correct path.
• Windows Time service: running, clock synced.
• claude.ai → Features → "Claude in Chrome": ON.
• Claude Desktop → Settings → Connectors → "Claude in Chrome": Enabled.

mcp__Claude_in_Chrome__list_connected_browsers from Cowork still returns "not connected" in this fully-clean post-reboot state. Every conceivable local cause is now eliminated.

Additional experiment that further isolates the bug to cloud relay

A community workaround for macOS (rename the local native-messaging-host manifest to .disabled, forcing the extension to fall back to a different connection mode) was adapted to Windows and applied:

1. Deleted the registry entry HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension.
2. Renamed the manifest file com.anthropic.claude_browser_extension.json → .json.disabled.
3. Killed every chrome.exe, Claude.exe, and chrome-native-host.exe process.
4. Restarted Chrome alone, then restarted Claude Desktop.

Result: the in-browser side panel continued to work (confirming it does not depend on the local native-messaging host at all — it talks to Anthropic's cloud directly), while Cowork's list_connected_browsers still returned "not connected". This eliminates local IPC / native-messaging routing as the cause and pins the bug unambiguously to the Anthropic-side cloud relay browser-discovery layer as it routes between this account's Cowork sessions and this account's Chrome browser.

Support-channel history

I have engaged Anthropic's in-product Fin AI Agent twice on this issue. Fin AI confirmed it cannot escalate to backend engineering and recommended this repo as the channel for "technical bugs requiring backend investigation."

Request

Please investigate the server-side browser-discovery binding for my account, or route this to the team that owns the Cowork-to-Chrome integration. I am happy to capture additional diagnostics (HAR, full DevTools network log, Claude Desktop debug log, registry export) on request.

cc: support@anthropic.com (emailing same diagnostic in parallel)

---

Suggested labels

area: claude-desktop, area: cowork, area: claude-in-chrome, bug, needs-triage

What Should Happen?

Desktop Claude should connect to chrome without any error

Error Messages/Logs

Steps to Reproduce

NA

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

NA

Claude Code Version

NA

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_