›_ Claude Code Issues
Claude Code Issues / #44541

[BUG] Chrome Connection not possible with Cowork!

Resolved 💬 3 comments Opened Apr 7, 2026 by PrimeCore24 Closed Apr 10, 2026

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?

Bug report: Claude in Chrome not connecting to Cowork

Title: Cowork shows "Claude in Chrome is not connected" while extension's WebSocket bridge is healthy (likely server-side stale state)

Environment

  • OS: macOS
  • Cowork: latest (desktop app)
  • Chrome extension: Claude in Chrome (Beta) v1.0.66, ID fcoeoabgfenejglbffodgkkbkcdhcgfn
  • Account: same personal account signed into both Cowork and the extension (verified email matches)

Symptom

Every Cowork browser-tool call (e.g. tabs_context_mcp) returns:

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

What I verified is NOT the cause

  • Extension is installed, enabled, signed in to the correct account.
  • Same account on Cowork and extension (personal, not Team).
  • Chrome fully quit and relaunched multiple times.
  • Cowork fully quit (from dock) and relaunched multiple times.
  • Disabled Claude Desktop's native messaging host by renaming ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json → disabled (per workaround in #33483). No effect.
  • Only one Cowork session running, no Claude Code CLI session active.

What I observed in the extension's service worker DevTools (Network tab)

The extension's bridge connection looks completely healthy on its side:

  • Repeated WebSocket upgrades to a session ID like 9d005f5a-c25f-490d-90a8-3bcc2aeb7e3f, status 101
  • profile and batch fetches returning 200
  • Initiators: mcpPermissions-*.js, PermissionManager-*.js
  • Console: no errors, "No Issues"

So the extension is talking to the bridge fine — but Cowork still reports the extension as not connected. This matches the failure mode described in #27055 / #32011 / #34058 / #25878, where the bridge holds stale server-side state that no client-side reset (logout, reinstall, cache clear) clears.

Request

Please reset the bridge state for this account / extension ID, or point me at a way to force a fresh bridge UUID from the client.

Related issues

  • #33483 — Claude in Chrome doesn't connect when Claude Desktop is also installed
  • #27055 — Bridge permanently rejects valid tokens, server-side stale state
  • #34058 — Bridge permanently fails with 'Invalid token or user mismatch'
  • #32011 — Misleading 'Invalid token or user mismatch' with no auto-recovery
  • #25878 — Bridge connection fails despite matching accounts

What Should Happen?

Bug report: Claude in Chrome not connecting to Cowork

Title: Cowork shows "Claude in Chrome is not connected" while extension's WebSocket bridge is healthy (likely server-side stale state)

Environment

  • OS: macOS
  • Cowork: latest (desktop app)
  • Chrome extension: Claude in Chrome (Beta) v1.0.66, ID fcoeoabgfenejglbffodgkkbkcdhcgfn
  • Account: same personal account signed into both Cowork and the extension (verified email matches)

Symptom

Every Cowork browser-tool call (e.g. tabs_context_mcp) returns:

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

What I verified is NOT the cause

  • Extension is installed, enabled, signed in to the correct account.
  • Same account on Cowork and extension (personal, not Team).
  • Chrome fully quit and relaunched multiple times.
  • Cowork fully quit (from dock) and relaunched multiple times.
  • Disabled Claude Desktop's native messaging host by renaming ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json → disabled (per workaround in #33483). No effect.
  • Only one Cowork session running, no Claude Code CLI session active.

What I observed in the extension's service worker DevTools (Network tab)

The extension's bridge connection looks completely healthy on its side:

  • Repeated WebSocket upgrades to a session ID like 9d005f5a-c25f-490d-90a8-3bcc2aeb7e3f, status 101
  • profile and batch fetches returning 200
  • Initiators: mcpPermissions-*.js, PermissionManager-*.js
  • Console: no errors, "No Issues"

So the extension is talking to the bridge fine — but Cowork still reports the extension as not connected. This matches the failure mode described in #27055 / #32011 / #34058 / #25878, where the bridge holds stale server-side state that no client-side reset (logout, reinstall, cache clear) clears.

Request

Please reset the bridge state for this account / extension ID, or point me at a way to force a fresh bridge UUID from the client.

Related issues

  • #33483 — Claude in Chrome doesn't connect when Claude Desktop is also installed
  • #27055 — Bridge permanently rejects valid tokens, server-side stale state
  • #34058 — Bridge permanently fails with 'Invalid token or user mismatch'
  • #32011 — Misleading 'Invalid token or user mismatch' with no auto-recovery
  • #25878 — Bridge connection fails despite matching accounts

Error Messages/Logs

Steps to Reproduce

Bug report: Claude in Chrome not connecting to Cowork

Title: Cowork shows "Claude in Chrome is not connected" while extension's WebSocket bridge is healthy (likely server-side stale state)

Environment

  • OS: macOS
  • Cowork: latest (desktop app)
  • Chrome extension: Claude in Chrome (Beta) v1.0.66, ID fcoeoabgfenejglbffodgkkbkcdhcgfn
  • Account: same personal account signed into both Cowork and the extension (verified email matches)

Symptom

Every Cowork browser-tool call (e.g. tabs_context_mcp) returns:

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

What I verified is NOT the cause

  • Extension is installed, enabled, signed in to the correct account.
  • Same account on Cowork and extension (personal, not Team).
  • Chrome fully quit and relaunched multiple times.
  • Cowork fully quit (from dock) and relaunched multiple times.
  • Disabled Claude Desktop's native messaging host by renaming ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json → disabled (per workaround in #33483). No effect.
  • Only one Cowork session running, no Claude Code CLI session active.

What I observed in the extension's service worker DevTools (Network tab)

The extension's bridge connection looks completely healthy on its side:

  • Repeated WebSocket upgrades to a session ID like 9d005f5a-c25f-490d-90a8-3bcc2aeb7e3f, status 101
  • profile and batch fetches returning 200
  • Initiators: mcpPermissions-*.js, PermissionManager-*.js
  • Console: no errors, "No Issues"

So the extension is talking to the bridge fine — but Cowork still reports the extension as not connected. This matches the failure mode described in #27055 / #32011 / #34058 / #25878, where the bridge holds stale server-side state that no client-side reset (logout, reinstall, cache clear) clears.

Request

Please reset the bridge state for this account / extension ID, or point me at a way to force a fresh bridge UUID from the client.

Related issues

  • #33483 — Claude in Chrome doesn't connect when Claude Desktop is also installed
  • #27055 — Bridge permanently rejects valid tokens, server-side stale state
  • #34058 — Bridge permanently fails with 'Invalid token or user mismatch'
  • #32011 — Misleading 'Invalid token or user mismatch' with no auto-recovery
  • #25878 — Bridge connection fails despite matching accounts

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

27055

Claude Code Version

27055

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗