[BUG] Claude in Chrome + Control Chrome Failures in Cowork Mode

[julian-molina]

Preflight Checklist

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

What's Wrong?

Bug Report: Claude in Chrome + Control Chrome Failures in Cowork Mode

Date: April 15, 2026
Reporter: Julian (claude2@freethinkster.com)
Environment: macOS, Claude Desktop (updated April 15, 2026), Chrome 147.0.7727.56
Account: claude2@freethinkster.com
Org UUID: 8fb00521-cc0c-4af3-92f0-7917a2aea19b

---

Summary

Two separate browser automation failures are completely blocking web access from within Cowork mode. Both issues appeared after Claude Desktop auto-updated on April 15, 2026.

1. Claude in Chrome extension fails to pair with Cowork session — the extension is installed, signed in with the correct account, and visible in Chrome, but tabs_context_mcp consistently returns "Claude in Chrome is not connected."
2. Control Chrome MCP (nicholmikey/chrome-tools-MCP) — execute_javascript and get_page_content tools fail with "Google Chrome is not running" regardless of Chrome's state, while other tools in the same MCP work correctly.

---

Issue 1: Claude in Chrome Extension Not Pairing with Cowork

Symptom

Every call to mcp__Claude_in_Chrome__tabs_context_mcp (with or without createIfEmpty: true) returns:

⚠️ Claude in Chrome is not connected
The Chrome extension isn't reachable right now.

Environment

• Claude Desktop updated April 15, 2026 (exact version not visible in UI)
• Chrome 147.0.7727.56 (confirmed via CDP /json/version endpoint)
• macOS (Intel Mac OS X 10_15_7, confirmed via Chrome user-agent)
• Claude in Chrome extension: installed, enabled, signed in as claude2@freethinkster.com
• Claude Desktop account: claude2@freethinkster.com (same account)

What Was Verified

• Extension is installed and visible in chrome://extensions/
• Extension settings page (chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/options.html#permissions) loads and shows the account as signed in: claude@freethinkster.com
• "Claude in Chrome" toggle is present in Claude Desktop Settings → Desktop app → Connectors
• No blocked sites are listed in Claude Desktop Settings → Desktop app → Claude in Chrome

Steps Taken to Resolve (All Failed)

1. Reloaded the Chrome extension from chrome://extensions/
2. Uninstalled and reinstalled the Claude in Chrome extension
3. Restarted Chrome (multiple times)
4. Restarted Claude Desktop (multiple times)
5. Updated Claude Desktop to the latest available version
6. Verified account match between Chrome extension and Claude Desktop (same email)
7. Tried from a freshly launched Chrome instance with --remote-debugging-port=9222
8. Tried from the original Chrome profile and from a fresh --user-data-dir profile

Result of Each Attempt

All attempts returned the same "Claude in Chrome is not connected" error from tabs_context_mcp. No change in behavior was observed across any configuration.

Related Known Issues (GitHub)

This appears to be the same regression documented in:

• Issue #26305 — Claude Code Desktop App (Conductor) – Chrome Extension Connection Failure (reported ~Feb 13, 2026)
• Issue #21371 — Claude in Chrome extension not connecting despite being installed
• Issue #24593 — Browser extension persistently fails to connect from CLI
• Issue #38783 — Cowork browser automation tools missing after Claude Desktop update

The connection failure appears to be a Desktop app regression where the app bundles its own Claude Code binary and either (a) has a bug in its Chrome/MCP integration, or (b) does not correctly read the global Chrome config after an update.

---

Issue 2: Control Chrome MCP — execute_javascript and get_page_content Always Fail

Background

Because Claude in Chrome was broken, the Control Chrome MCP (nicholmikey/chrome-tools-MCP) was installed as an alternative for browser content access.

Symptom

execute_javascript and get_page_content consistently return:

Error: Google Chrome is not running. Please launch Chrome and try again.

This occurs regardless of Chrome's state. Meanwhile, list_tabs, open_url, get_current_tab, reload_tab, and close_tab all work correctly in the same session.

Key Diagnostic Finding: Split Behavior

The MCP server has a two-track behavior:

• Navigation tools (list_tabs, open_url, get_current_tab, reload_tab) — use the Chrome Extension API. Work correctly; list_tabs returns valid tab IDs in Chrome Extension integer format.
• Content tools (execute_javascript, get_page_content) — use Chrome DevTools Protocol (CDP) via WebSocket on localhost:9222. Fail with the above error.

Exhaustive Debug Steps and Results

Step 1 — Chrome running normally (no debug port):
execute_javascript → Error: Google Chrome is not running
list_tabs → returns correct tabs ✓

Step 2 — Launched Chrome with open -a "Google Chrome" --args --remote-debugging-port=9222:
Port did not open. Chrome was already running; macOS open -a passes flags only on first launch, so the flag was ignored. localhost:9222/json/version returned ERR_CONNECTION_REFUSED.

Step 3 — Quit Chrome (Cmd+Q), then relaunched with open -a "Google Chrome" --args --remote-debugging-port=9222:
Port still did not open. Chrome opened a new window without applying the flag (possible session restore or macOS Launch Services behavior).

Step 4 — Launched via full binary path with fresh profile:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-debug &

Port opened successfully. localhost:9222/json/version returned full JSON:

{
  "Browser": "Chrome/147.0.7727.56",
  "Protocol-Version": "1.3",
  "webSocketDebuggerUrl": "ws://localhost:9222/devtools/browser/22d2c419-5641-494f-9fe8-ce0591177c5b"
}

CDP confirmed active. Restarted Claude Desktop to allow MCP server to reconnect.
execute_javascript → STILL Error: Google Chrome is not running
list_tabs → returned correct tab ✓

Step 5 — Navigated to real webpage (example.com) to rule out internal Chrome page restriction:
execute_javascript → STILL Error: Google Chrome is not running

Step 6 — Verified AppleScript access to Chrome:

osascript -e 'tell application "Google Chrome" to get URL of active tab of front window'

Returned the current tab URL correctly. AppleScript can access Chrome. This rules out macOS Automation/Accessibility permission issues.

Step 7 — Killed fresh-profile Chrome, relaunched with original profile + debug port:

pkill -f "chrome-debug"
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 &

Chrome opened with original profile (Claude in Chrome extension visible and signed in).
However: localhost:9222/json/version → ERR_CONNECTION_REFUSED — port did not open.
This is because the pkill -f "chrome-debug" only killed the fresh-profile instance; the original Chrome (without debug port) was still running in the background, so the binary command opened a new window in the existing instance without applying the flag.

Step 8 — Completely quit all Chrome instances (Cmd+Q), relaunched with binary + original profile:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 &

Chrome opened with original profile. Claude in Chrome extension confirmed present.
localhost:9222/json/version → ERR_CONNECTION_REFUSED (port STILL not open).
Root cause unknown — Chrome binary launched directly via Terminal with the flag, but the port does not bind. This may be a macOS security restriction, a Chrome policy, or the launch process being captured by a running Chrome parent process.

Step 9 — After fresh-profile launch (Step 4, where port DID open), compared tool behavior:
list_tabs returns integer tab IDs (Chrome Extension API format, e.g., 2109890274), not UUID-format CDP target IDs. This confirms list_tabs uses a browser-side Chrome Extension, not CDP HTTP.
Yet execute_javascript still fails with the port confirmed open.
Hypothesis: The browser-side Control Chrome extension is not installed in the fresh --user-data-dir=/tmp/chrome-debug profile. execute_javascript requires the extension's content scripts, not raw CDP. The extension only exists in the original Chrome profile.

Root Cause Summary

The content tools (execute_javascript, get_page_content) appear to require either:

• A browser-side Control Chrome Chrome extension (which would only be present in the original Chrome profile), AND/OR
• A CDP WebSocket connection on port 9222

When using the original Chrome profile, port 9222 cannot be opened reliably via Terminal binary launch. When using a fresh profile (where port 9222 opens successfully), the browser-side extension is absent. These two requirements cannot currently be satisfied simultaneously through available user-facing configuration.

---

Combined Impact

Both failures together mean that Cowork mode has zero browser content access. The session cannot read web pages. WebFetch is also blocked by the network egress proxy for essentially all external domains (returns EGRESS_BLOCKED for runwayml.com, lumalabs.ai, arxiv.org, github.com, npmjs.com, d5render.com, and dozens of others). The only remaining web access tool is WebSearch, which returns search snippet previews only.

This combination completely prevents web research tasks from being executed with adequate source quality.

---

Requested Actions

1. Investigate and fix the Claude in Chrome pairing failure in Cowork — this is the highest-priority item. The extension connects successfully in the browser, but the Cowork session never receives the handshake. This regression correlates with the April 15, 2026 Desktop update.

2. Clarify the Control Chrome MCP setup requirements — specifically: (a) does the content access path require a browser-side Chrome extension in addition to the Claude Desktop MCP server? (b) is there a supported way to launch Chrome with --remote-debugging-port=9222 while using the original user profile on macOS?

3. Consider relaxing the EGRESS_BLOCKED proxy policy for common research and documentation domains (GitHub, npmjs, arxiv.org, tool vendor sites), or document which domains are accessible so users can understand the scope of web access.

---

Session Reference

• Session ID: 70f4cbd5-19ff-4a65-9851-f1e47a5e5848
• Session started: April 14–15, 2026
• Claude Desktop org UUID: 8fb00521-cc0c-4af3-92f0-7917a2aea19b

What Should Happen?

Full report on first box.

Error Messages/Logs

Full report on first box.

Steps to Reproduce

Full report on first box.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude 1.2581.0 (f10398) 2026-04-14T17:16:40.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] claude-in-chrome MCP: tabs_context_mcp always returns "Browser extension is not connected" despite extension showing connected #48410
2. [BUG] Claude in Chrome v1.0.66 — not connected in Cowork mode despite native host running (macOS, April 2026) #43935
3. [BUG] macOS Cowork: Claude in Chrome shows INCLUDED but sessions receive zero browser tools — regression starting ~April 10 #47148

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[houserooms]

Adding a data point. 17 April 2026, macOS Sequoia, Claude Desktop latest, Chrome latest, extension latest, subscription auth, matching accounts.

Same symptoms:

• tabs_context_mcp → "Claude in Chrome is not connected".
• Extension shows as connected inside Chrome.
• Desktop Connector toggle is on.
• Full Chrome quit & relaunch: no effect.
• Full Desktop app quit & relaunch: no effect.

Regression correlates exactly with the 15 April Desktop auto-update here too. Before 15 April the feature was working. This is the second major Chrome-connection regression in 4 weeks (previous one 20 March, see #38845 / #36910).

Please treat as P0. For many users this is the feature they bought the subscription for.

[m13v]

hit the same pairing failure on 15 April after the auto-update. spent an afternoon on it before giving up and going back to driving chrome via CDP on port 9222 directly. the native messaging handshake between Desktop and the extension is where this breaks. the host binary path in the extension manifest points into the Desktop.app bundle, and when Desktop updates it rewrites that path mid-flight without reloading the registered host. you can verify with lsof -p $(pgrep -f 'Claude Helper') and compare the bundle path to what chrome has registered in ~/Library/Application Support/Google/Chrome/NativeMessagingHosts. going fully accessibility-API based (AXUIElement on the chrome process) dodged this entirely for me, no handshake to break.

[hsonvu1912]

Subject: Claude in Chrome bridge - persistent "Invalid token or user mismatch"

Email: hsonvu1912@gmail.com
Account ID: 94fb62eb-93e7-40ea-9126-855a3d6a7fb8
Organization ID: 95f0a38a-da05-4431-bb98-fefc776d54f3

Issue: Chrome extension "Claude in Chrome" cannot connect via Cowork bridge
since 2026-03-06 (989+ failed attempts logged).

Error pattern (repeats with exponential backoff):
[Claude in Chrome] Connecting to bridge:
wss://bridge.claudeusercontent.com/chrome/94fb62eb-93e7-40ea-9126-855a3d6a7fb8
[Claude in Chrome] Bridge error: Invalid token or user mismatch
[Claude in Chrome] Bridge connection closed (code: 1008)

Troubleshooting performed (none fixed the issue):

• Uninstalled + reinstalled Chrome extension multiple times
• Full Desktop state reset: deleted config.json (encrypted OAuth cache),
  Network folder (cookies), IndexedDB, Local Storage, Session Storage,
  Cache, local-agent-mode-sessions// folder
• Completed fresh OAuth flow via browser after wipe
• Chrome extension and Desktop both signed into same email

After wipe + fresh login, login API returns same accountId 94fb62eb-...
but bridge API still rejects with "user mismatch". This appears to be
backend inconsistency between auth.anthropic.com and
bridge.claudeusercontent.com for this account.

Attaching main.log (filter for "bridge|mismatch" for relevant lines).
Desktop version: Claude 1.1.4498.0 UWP (Windows 11).