Claude in Chrome: extension never registers with cloud-hosted Cowork sessions, while local chats connect fine

Claude in Chrome: extension never registers with cloud-hosted Cowork sessions, while local chats connect fine
Summary
On the same Mac, same Chrome profile, and same Claude Desktop install, the Claude in Chrome extension connects normally for regular chats in the desktop app, but is never reachable from a Cowork task running in the cloud sandbox. From the cloud session, list_connected_browsers returns an empty array and every browser tool fails with "Browser extension is not connected."

All local prerequisites verify clean: the native messaging manifest is present and current, its path points to an existing executable helper binary, the installed extension ID is listed in allowed_origins, and the extension's service worker is active. There is no Claude Code CLI native host registered, so this is not the extension-ID conflict described in #29057 — that manifest does not exist on this machine.
Environment

OS
macOS (version:15.5 (24F74))
Chrome version
Version 151.0.7922.71 (Official Build) (arm64)
Claude in Chrome extension
1.0.84
Extension ID
fcoeoabgfenejglbffodgkkbkcdhcgfn
Claude Desktop
Claude 1.24012.11 (09114b) 2026-08-03T15:24:21.000Z
Claude Code CLI
Installed, but no browser native host registered
Session type
Cowork task, cloud-hosted sandbox, launched from Claude Desktop
Model
claude-opus-5
Date observed
2026-08-04

Observed behavior
From the cloud Cowork session:

list_connected_browsers -> []

tabs_context_mcp -> "Browser extension is not connected. Please ensure the

Claude browser extension is installed and running..."

switch_browser -> "No other browsers available to switch to. Open Chrome

with the Claude extension in another browser to switch."

switch_browser is notable: it is documented to broadcast a Connect prompt to every Chrome instance with the extension installed and wait up to two minutes. No prompt ever appeared in Chrome, and it returned immediately. The extension is not registering as an available browser for this session at all — this is not a tab-selection or permission-scope failure.
Expected behavior
The extension should register as a connected browser and be reachable from a cloud Cowork session, as it is from a regular desktop chat.
Verification performed
Every component in the local chain was checked and is healthy.

1. Native messaging manifest — present, rewritten at Desktop launch

$ ls -la ~/Library/Application\ Support/Google/Chrome/NativeMessagingHosts/

total 8

drwx------@ 3 rob staff 96 May 7 11:07 .

drwx------@ 60 rob staff 1920 Aug 4 08:10 ..

-rw-r--r--@ 1 rob staff 411 Aug 4 08:09 com.anthropic.claude_browser_extension.json

The 08:09 mtime is from the Claude Desktop restart performed during troubleshooting, so Desktop is registering its host correctly on launch.

1. Manifest contents — installed extension ID is allowed

{

"name": "com.anthropic.claude_browser_extension",

"description": "Claude Browser Extension Native Host",

"path": "/Applications/Claude.app/Contents/Helpers/chrome-native-host",

"type": "stdio",

"allowed_origins": [

"chrome-extension://dihbgbndebgnbjfmelmegjepbnkhlgni/",

"chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/",

"chrome-extension://dngcpimnedloihjnnfngkgjoidhnaolf/"

]

}

The installed extension's ID (fcoeoabgfenejglbffodgkkbkcdhcgfn, read from chrome://extensions with Developer mode enabled) is the second entry. Match confirmed.

1. Helper binary — exists and is executable

$ ls -l /Applications/Claude.app/Contents/Helpers/chrome-native-host

-rwxr-xr-x@ 1 rob staff 2080464 Aug 3 15:34 /Applications/Claude.app/Contents/Helpers/chrome-native-host

1. No competing Claude Code native host — #29057 does not apply

The user-level directory contains only the Desktop manifest; there is no com.anthropic.claude_code_browser_extension.json. The system-level directory contains no Anthropic entries:

$ ls -la /Library/Google/Chrome/NativeMessagingHosts/

com.adobe.acrobat.chrome_webcapture.json

com.apple.passwordmanager.json -> /System/Cryptexes/App/Library/Google/Chrome/NativeMessagingHosts/com.apple.passwordmanager.json

Claude Code CLI is installed on this machine but has not registered a browser native host, so the shared-extension-ID contention described in #29057 is not the cause here.

1. Extension service worker — active

chrome://extensions shows the Claude card with "Inspect views service worker, 1 more..." — i.e. running. (For contrast, the Google Docs Offline card on the same page reads "service worker (Inactive)".)

1. Connector — enabled

"Claude in Chrome" is toggled on in the chat-level connector menu. Toggling it off disconnects the claude-in-chrome MCP server from the session entirely and toggling it back on reconnects it, so the connector plumbing between the session and the MCP server is working. The failure is downstream of that, between the MCP server and the browser.
Steps already taken (none resolved it)
Updated the extension via chrome://extensions → Update
Disabled and re-enabled the extension
Fully quit (⌘Q) and relaunched Chrome
Fully quit (⌘Q) and relaunched Claude Desktop
Restarted in both orders (Chrome first, Desktop first)
Toggled the Claude in Chrome connector off and back on
Called switch_browser to broadcast a pairing request — no prompt appeared in Chrome
Confirmed the same Chrome profile is signed in to claude.ai under the account running the session
Key discriminator
On this machine, SOME regular chats in the Claude desktop app reach the extension without issue — the user has multiple such chats doing browser automation successfully, in the same Chrome, with the same extension, concurrent with the failures. Other sessions fail including cloud-hosted Cowork session, sessions in free chats, and sessions in the same project as the working sessions.

This suggests the problem is not in the local native messaging setup (which the checks above confirm is intact) but in the path by which a cloud-hosted session reaches the locally-connected extension — the extension appears never to register itself as remotely-available, so the cloud session sees an empty browser list.
Reproduction
On macOS with Claude Desktop installed and the Claude in Chrome extension connected and working in regular desktop chats
Start a Cowork task that runs in the cloud (not "On your computer")
Enable the Claude in Chrome connector for that task
Call any browser tool, e.g. tabs_context_mcp

Expected: the extension is reachable. Actual: list_connected_browsers returns []; all browser tools fail with "Browser extension is not connected."
Note on intermittency
The user reports this is not fully deterministic across sessions — some chats connect and others do not, both inside and outside projects, without an obvious pattern. That may point to a race or a stale binding at session start rather than a hard configuration fault, and is consistent with the local configuration being valid throughout.