[BUG] macOS Cowork: Claude in Chrome shows INCLUDED but sessions receive zero browser tools — regression starting ~April 10
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?
Cowork sessions launch with zero browser tools despite Claude in Chrome being properly installed, enabled, and showing as INCLUDED under Desktop connectors. No browser tools (navigate, click, read_page, screenshot, tabs_context_mcp, etc.) are registered in the session at all. When asked to perform any browser task, the session searches the connector registry, finds nothing, and reports it has no browser capability.
This was working correctly until approximately April 10, 2026. Chrome still has tab groups from prior successful Claude-controlled browser sessions, confirming the integration was functional before.
What Should Happen?
New Cowork sessions should detect the Claude in Chrome extension via the native messaging host and register browser tools (navigate, click, read_page, screenshot, tabs_context_mcp, etc.) so the session can control Chrome for browser-based tasks. This is how it worked prior to ~April 10.
Error Messages/Logs
No explicit error messages. The failure is silent — browser tools simply never appear in the session's available tools. When the session attempts to find browser capability, it reports:
"I don't currently have that connection available in this session."
"Connector search: 0 connectors found"
"There's no Chrome browser connector available in the registry right now."
Steps to Reproduce
STEPS TO REPRODUCE:
Verify Claude in Chrome extension v1.0.66 is installed and enabled in chrome://extensions
Verify native messaging host config exists at ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json with correct contents (path pointing to /Applications/Claude.app/Contents/Helpers/chrome-native-host, extension ID in allowed_origins)
Verify the binary at /Applications/Claude.app/Contents/Helpers/chrome-native-host exists and is executable
Open Claude Desktop, confirm "Claude in Chrome" shows as INCLUDED under Desktop → Connectors
Quit Chrome (Cmd+Q) and Claude Desktop (Cmd+Q) completely
Reopen Chrome, then Claude Desktop
Start a new Cowork session
Ask: "navigate to example.com"
Session reports no browser tools available
Verified that all of the following are correct and none resolve the issue:
Native messaging host JSON exists with correct path and extension ID (fcoeoabgfenejglbffodgkkbkcdhcgfn) in allowed_origins
Binary exists and is executable (last modified April 10)
Extension is ON with all permissions including "Communicate with cooperating native applications" and site access "On all sites"
Service worker and offscreen.html both running
No error badges on extension in Developer mode
Complete extension uninstall + reinstall from Chrome Web Store does not fix it
Multiple full restart cycles of both Chrome and Claude Desktop do not fix it
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown exact version number. Last working approximately April ~10, 2026 — the same date the chrome-native-host binary was last modified, suggesting a Claude Desktop update that day.
Claude Code Version
2.1.104 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Why this is a new issue — reviewed related reports:
#44541 (Chrome connection not possible with Cowork, closed April 10 as duplicate) — That issue reported tabs_context_mcp calls returning "Chrome extension isn't reachable" errors, meaning browser tools were present but failing. In my case, zero tools are ever registered in the session. There is nothing to call.
#46869 (Extension connects in Desktop but not terminal CLI) — Opposite problem. That user's Desktop/Cowork works; only their terminal CLI is broken.
#38783 (Windows: browser tools missing after update) — Same symptom class but Windows. That user saw tools drop from 19 to 3. I see a drop from full functionality to 0.
#46487 (Cowork VM connection timeout, Windows) — Different platform, different failure mode (VM won't connect vs. VM works but lacks browser tools).
#39011 (URL parsing failure after reconnection, macOS) — Mid-session reconnection issue. My issue is present from the very start of every new session.
Additional observations:
The native messaging host JSON file was found missing on April 12 before being regenerated (likely by a prior troubleshooting attempt or app restart). Even after full restoration of all components, the issue persists.
Chrome retains tab groups from prior successful Claude browser sessions, proving the extension and native messaging pipeline were functional before the regression.
The chrome-native-host binary's last-modified date of April 10 aligns with when the integration stopped working, suggesting a Claude Desktop update touched this file.
Hypothesis: The April 10 Claude Desktop update may have disrupted the handshake between Cowork session initialization and the Chrome extension bridge. Possibly related to the "server-side stale state" root cause identified in #44541, but manifesting as total tool absence rather than connection errors on existing tools.
4 Comments
Update: Regression likely coincides with Chrome 147 update on macOS.
After extensive debugging, I believe this regression coincides with Chrome auto-updating from 146 to 147 around April 8-10. Several other reporters describe the same symptoms and specifically name Chrome 147:
--remote-debugging-port=9222appears to be ignored on macOS in Chrome 147.0.7727.55Note: those issues are being auto-closed as duplicates of older pre-147 issues (#40758, #37833, #45227), which may be obscuring the pattern that a new regression arrived with Chrome 147.
What I've ruled out on my end:
fcoeoabgfenejglbffodgkkbkcdhcgfn) in allowed_origins/Applications/Claude.app/Contents/Helpers/chrome-native-host: exists, executable, last modified April 9It's possible this is a Claude Desktop update issue that landed at the same time, but the Chrome 147 correlation across multiple independent reporters is worth investigating.
Update: Found a workaround.
Clicking the Claude in Chrome extension icon in the Chrome toolbar before starting a Cowork session appears to restore browser tools. The service worker needs to be manually woken up — Chrome 147 seems to have changed service worker initialization behavior so it no longer auto-starts when Cowork requests the connection.
Steps: click the Claude extension icon in Chrome → start a new Cowork session (or retry in existing session) → browser tools appear.
This supports the hypothesis that Chrome 147 changed how/when extension service workers initialize, breaking the assumption that the native messaging host can wake the service worker on demand.
Update: resolved on my end. Root cause was not a Cowork/Desktop bridge regression, but silent failure of the Chrome-integration subscription check. My CLI was auto-authing via ANTHROPIC_API_KEY env var (showing "API Usage Billing" / managed key in /status), which routes through Anthropic API billing and doesn't carry my claude.ai Team subscription. Running /login in the CLI and selecting option 1 ("Claude account with subscription") re-authed me against my Team seat. /status flipped to "Login method: Claude Team account" and Chrome integration registered immediately (claude-in-chrome MCP connected, /chrome command appeared, browser tools worked end-to-end).
The failure mode was particularly confusing because: (a) no error was surfaced — the --chrome flag silently did nothing, (b) /chrome returned "No commands match" giving the impression of a version/feature mismatch, and (c) Cowork exposed browser_batch tool schemas to the model despite the gate, so agents in Cowork sessions could "see" the tools and attempt calls that all returned "No tab available."
Suggested improvement: when --chrome is invoked on an API-key-authed session, surface a clear error like "Chrome integration requires a claude.ai subscription; your current session is authed via API key. Run /login and select option 1 to switch identities."
Filing this in case the same root cause explains the Cowork-session "0 browser tools" symptom for others — particularly users whose orgs use API-key provisioning for Claude Code.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.