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 ([email protected])
Environment: macOS, Claude Desktop (updated April 15, 2026), Chrome 147.0.7727.56
Account: [email protected]
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 [email protected]
• Claude Desktop account: [email protected] (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: [email protected]
• "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