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

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/48410
2. https://github.com/anthropics/claude-code/issues/43935
3. https://github.com/anthropics/claude-code/issues/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

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.

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.

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/<accountId>/ 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).

I am hitting the same issue. Are there any workarounds? I am on Claude desktop app 1.4758.0 on Mac Air.

Bug Report: Claude in Chrome MCP disconnected in Cowork

Issue: Claude in Chrome MCP stopped connecting to Cowork
When: Started on April 28, 2026 morning (was working on April 27)
Affected devices: Two separate computers, same issue on both
Extension status: Installed, signed in with correct account ([hugohouse01@gmail.com](mailto:hugohouse01@gmail.com))
Steps taken: Reinstalled extension, restarted Chrome (applied pending update), restarted Cowork app — issue persists
Note: No Claude Code installed, so no conflict between the two

Subject: Claude in Chrome bridge persistently rejects OAuth token (Issue #48806)

Hi,

I'm experiencing a persistent "Invalid OAuth token" error when Claude Desktop /
Cowork tries to connect to the Claude in Chrome WebSocket bridge. This appears
to be the same issue as GitHub #48806. After exhaustive local-state cleanup,
the bridge keeps rejecting authentication, which strongly suggests an
account-level or server-side state issue that needs to be reset on your end.

═══════════════════════════════════════════════════
ENVIRONMENT
═══════════════════════════════════════════════════

• Account: celina@thetawave.ai
• Account created: April 15, 2026 (~14 days ago)
• macOS (Apple Silicon)
• Claude Desktop: 1.4758.0
• Claude Code (embedded): 2.1.119
• Chrome extension "Claude": v1.0.69

(ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)

• Google Chrome: 147.0.7727.102

═══════════════════════════════════════════════════
EXACT ERROR (from ~/Library/Logs/Claude/main.log)
═══════════════════════════════════════════════════
Repeating every ~30 seconds:

[Claude in Chrome] Connecting to bridge:
wss://bridge.claudeusercontent.com/chrome/<session-id>
[Claude in Chrome] WebSocket connected, sending connect message
[Claude in Chrome] Bridge error: Invalid OAuth token
[Claude in Chrome] Bridge connection closed (code: 1008, duration: 0ms)

Close code 1008 = policy violation, indicating the server is actively
rejecting the token rather than the token being malformed.

═══════════════════════════════════════════════════
SYMPTOMS
═══════════════════════════════════════════════════

• All mcp__Claude_in_Chrome__* tools fail with:

"Claude in Chrome is not connected"

• Cowork tasks cannot use the Claude in Chrome integration at all
• The Chrome extension itself works fine in standalone mode

(side panel chat with Sonnet 4.6 controls the browser correctly)

• Control Chrome (the separate chrome-control plugin) DOES work —

only the Claude in Chrome bridge path is broken

• Account is consistent: same email signed in to Desktop and

Chrome extension

═══════════════════════════════════════════════════
LOCAL FIXES ATTEMPTED (none resolved the issue)
═══════════════════════════════════════════════════

1. Reinstalled Chrome extension multiple times
2. Full quit + relaunch of Chrome and Claude.app
3. Signed out and back in to Claude Desktop
4. Logged out of claude.ai in Chrome browser, cleared site data

(cookies, IndexedDB, Service Worker for claude.ai and claudeusercontent.com),
re-logged in

1. Deleted ~/Library/Application Support/Claude/bridge-state.json
2. Deleted "Claude Safe Storage" keychain entry (the master encryption key,

from 2026-04-10) and all "Claude Code-credentials-*" keychain entries

1. Ran: claude --settings '{"forceLoginMethod":"claudeai"}' /login
2. Verified Connector "Claude in Chrome" toggle is enabled in Settings
3. Restarted multiple times after each step
4. Confirmed extension calls connectNative correctly with both

"com.anthropic.claude_browser_extension" (Desktop) and
"com.anthropic.claude_code_browser_extension" (Code) host names

The bridge URL session ID and the rejection error remain identical across
all of the above. The new OAuth token issued by fresh login is rejected
just like the old one — pointing to server-side state, not local state.

═══════════════════════════════════════════════════
WHAT I NEED
═══════════════════════════════════════════════════
Please reset / re-provision the Claude in Chrome bridge auth binding for my
account on the server side. I suspect the bridge has cached invalid
authorization metadata for celina@thetawave.ai that no client-side action
can clear.

I am happy to provide additional logs, run any diagnostic commands, or
get on a call.

Thanks,
Celina

Same issue here on macOS. Fresh install of Claude Desktop today, fresh Chrome profile, the Claude in Chrome extension is paired and working in the Chrome sidebar (it can navigate and browse fine), but Cowork mode keeps returning "Claude in Chrome is not connected" every time I try to use a browser tool there.

Started failing on April 27, 2026. It was working the night before with no settings changed.

Things I tried that did not fix it: full reset and reinstall of Claude Desktop, full reset of Chrome, reinstalling the extension, creating a new Chrome profile, rebooting the Mac, verifying all toggles in Capabilities and Connectors are enabled.

Confirming this is reproducible and currently affecting my workflow.

@Celinaguo11 @jaliliitdpt-rgb

Could you perform the following, find the Claude extension in the list of your Chrome extensions, right click on the triple dot and select "Manage Extension". Click on "service_worker.html", that should bring up a DevTools window. Select the Network tab.

In Chrome, go to the following URL: https://clau.de/chrome/reconnect

that will force bridge to reconnect, you should see some activity there including a connection to a long UUID. Click on that, then select the Messages tab (next to Headers), you should ideally see some messages like "ping", "pong", every few seconds. The very first message in the list should appear to be a successful connection message. On the headers tab you should see the URL go to wss://bridge.claudeusercontent.com/chrome/<uuid>, note the uuid (not necessary to post this).

In the DevTools Console from the service_worker.html, run the following:

chrome.storage.local
  .get(["accessToken", "refreshToken", "accountUuid", "tokenExpiry", "bridgeDeviceId"])
  .then((s) =>
    console.log({
      hasAccessToken: !!s.accessToken,
      hasRefreshToken: !!s.refreshToken,
      hasAccountUuid: !!s.accountUuid,
      hasBridgeDeviceId: !!s.bridgeDeviceId,
      tokenExpiryMsFromNow: s.tokenExpiry ? s.tokenExpiry - Date.now() : null,
    }),
  );

If you are seeing authentication issues with the bridge, please try the following:
open the sidepanel (click on the extension to open this). Click on the triple dot in the upper right, go to Settings -> Log Out, then log back in.

Could you also sign out and sign back in within the Desktop app as well?

[Claude in Chrome] Bridge error: OAuth token forbidden (403) — missing
scope or org access
[Claude in Chrome] Bridge connection closed (code: 1008, duration: 0ms)

On Tue, Apr 28, 2026 at 9:04 PM ekolve-ant @.***> wrote:

ekolve-ant left a comment (anthropics/claude-code#48806) <https://github.com/anthropics/claude-code/issues/48806#issuecomment-4337481918> @Celinaguo11 <https://github.com/Celinaguo11> @jaliliitdpt-rgb <https://github.com/jaliliitdpt-rgb> Could you perform the following, find the Claude extension in the list of your Chrome extensions, right click on the triple dot and select "Manage Extension". Click on "service_worker.html", that should bring up a DevTools window. Select the Network tab. In Chrome, go to the following URL: https://clau.de/chrome/reconnect that will force bridge to reconnect, you should see some activity there including a connection to a long UUID. Click on that, then select the Messages tab (next to Headers), you should ideally see some messages like "ping", "pong", every few seconds. The very first message in the list should appear to be a successful connection message. On the headers tab you should see the URL go to wss://bridge.claudeusercontent.com/chrome/, note the uuid (not necessary to post this). In the DevTools Console from the service_worker.html, run the following: chrome.storage.local .get(["accessToken", "refreshToken", "accountUuid", "tokenExpiry", "bridgeDeviceId"]) .then((s) => console.log({ hasAccessToken: !!s.accessToken, hasRefreshToken: !!s.refreshToken, hasAccountUuid: !!s.accountUuid, hasBridgeDeviceId: !!s.bridgeDeviceId, tokenExpiryMsFromNow: s.tokenExpiry ? s.tokenExpiry - Date.now() : null, }), ); If you are seeing authentication issues with the bridge, please try the following: open the sidepanel (click on the extension to open this). Click on the triple dot in the upper right, go to Settings -> Log Out, then log back in. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/48806#issuecomment-4337481918>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CCY3C5X6R5XDAWJNXVZWH334YDQCHAVCNFSM6AAAAACX2ZH4KSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMZXGQ4DCOJRHA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: @.***>

--
Jalili Real Estate LLC
IT. Department
Office: 1701-1702
The Tower Plaza Hotel (Office Building)

Bug Description

After Claude in Chrome updated to v1.0.69 on April 28, 2026,
the Chrome MCP connection in Cowork immediately drops every time
it connects. The native host starts successfully, but Chrome
disconnects within seconds (EOF received), causing Cowork to
show "Claude in Chrome is not connected."

Environment

• Claude in Chrome: v1.0.69
• Platform: Windows (two separate computers, same issue on both)
• Claude Code installed: No

Timeline

• Working normally until April 27, 2026
• Broke on April 28 morning after extension auto-updated to v1.0.69
• Last successful session in logs: April 20, 2026

Log Evidence (chrome-native-host.log)

The log shows the native host starts and creates the pipe
successfully, but Chrome immediately disconnects:

[2026-04-28 10:33:30] Chrome disconnected (EOF received)
[2026-04-28 10:33:31] Chrome native host starting → pipe created → listening
[2026-04-28 10:52:46] Chrome disconnected (EOF received)
[2026-04-28 10:52:55] Chrome native host starting → pipe created → listening
[2026-04-28 11:12:17] Chrome disconnected (EOF received)
[2026-04-28 11:14:26] Chrome disconnected (EOF received)

(Full log attached)

Impact

High — Chrome MCP is completely non-functional.
All browser automation tasks in Cowork are blocked.

Steps to Reproduce

1. Have Claude in Chrome v1.0.69 installed
2. Open Cowork
3. Attempt any Chrome MCP tool call
4. Result: "Claude in Chrome is not connected"

chrome-native-host.log

+1 — confirmed on macOS 14, Claude Max, single account, single Chrome instance.

Adding asymmetric evidence: in my Cowork session, Claude in Chrome MCP is fully dead while Control Chrome MCP still works. This issue title may be capturing two different breakage modes that need separating.

Symptom A — Claude in Chrome MCP (DEAD in Cowork)

mcp__Claude_in_Chrome__* tools load via ToolSearch. Every call returns instantly:

list_connected_browsers → "Claude in Chrome is not connected"
tabs_context_mcp(createIfEmpty=true) → "Claude in Chrome is not connected"
switch_browser → "Claude in Chrome is not connected"
(instant return — no broadcast, no 2-min wait)

switch_browser returning instantly without broadcasting is the tell — there's no listening peer for the MCP server to reach.

Tried, no effect:

• Quit + relaunch Cowork (multiple times)
• Quit + relaunch Chrome
• Disable + re-enable extension
• Single account on Cowork and extension (personal, not Team)
• Confirmed extension installed, signed in, mic granted, options page loads cleanly

Symptom B — Control Chrome MCP (ALIVE in Cowork, in my setup)

Same Cowork session, same Chrome, same moment:

mcp__Control_Chrome__list_tabs() → returned my open tabs cleanly, full URLs + titles

This contradicts the title of this issue. Either:

• The original reporter's Control Chrome was broken by config-specific factors
• Or there's variance across Cowork builds / extension versions / Chrome profile state

Useful context either way. Control Chrome is a partial workaround for navigation but can't substitute for Claude in Chrome when you need realistic mouse + hover events (it's all JavaScript dispatch, no visible cursor).

Symptom C — Claude Code CLI fallback also blocked (NEW)

Per #38475's note that the env-var workaround fixes CLI sessions:

$ export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
$ claude # v2.1.123, Opus 4.7

> Bash: echo "ENV=$CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC"
ENV=1 # env var inherited

> Bash: claude mcp list 2>&1 | head -50
# 20 servers (Composio, Gmail, Drive, Calendar, claude-peers,
# claude-mem, stitch, plus claude.ai integrations).
# NONE are claude-in-chrome.

> ToolSearch: query="claude-in-chrome"
→ No matching deferred tools found.

> grep -r claude-in-chrome ~/.claude/
# Hits only in old session history and doc references.
# No active server config.

So claude-in-chrome is not registered as an MCP server out-of-the-box in Claude Code CLI v2.1.123. The env-var workaround in #38475 presupposes the server is configured but blocked from connecting. On a fresh Mac it isn't.

Net effect

No documented path from a clean install to a working Claude-in-Chrome MCP session for screen-recording-grade browser automation:

• Cowork: bridge dead, env-var unreachable
• Claude Code CLI: server not registered
• Control Chrome in Cowork: alive but JS-only, no cursor, can't substitute for the hero shot

Asks

1. CLI side: Either ship claude-in-chrome pre-registered in Claude Code, or document the claude mcp add command/URL that adds it.
2. Cowork side: Pass CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 (or whatever the underlying fix is) into the child Claude Code process. A user-facing toggle in Cowork → Settings → Connectors would be enough.
3. This issue: Consider splitting it — Claude in Chrome and Control Chrome have different failure modes in Cowork.

Related: #38475, #44541.

+1, hitting this exact regression on macOS Cowork.

Environment:

• macOS 15.7.3 (24G419)
• Chrome 147.0.7727.119
• Claude Desktop 1.5354.0
• Claude in Chrome connector toggle: enabled
• Extension permissions: "On all sites"
• Same Anthropic account across desktop and extension

Symptom: every browser tool call from Cowork returns "Claude in Chrome is not connected. The Chrome extension isn't reachable right now." Worked fine as recently as Sunday April 26, broke since.

Tried (none resolved): Chrome restart, Cowork restart, laptop restart, extension uninstall + reinstall, connector toggle off/on with 60 second wait, fresh Cowork conversation, account match verification.

Notable: ~/Library/Logs/Claude/mcp*.log shows no Chrome-related entries from the failed connection attempts. Suggests the MCP isn't even initiating a handshake from Cowork's side, matching the "stale server-side bridge state" hypothesis in the original report.

Impact: blocks all browser-driven workflows. Falling back to manual screenshots is costing several hours a day.

Requesting either a server-side bridge reset for affected accounts or an ETA on the fix.

Adding a Windows data point. Same symptom as the original report: extension installed, signed in, visible in Chrome, but Cowork's Browser Use panel shows "No browsers connected" and Recheck does nothing.
Environment

OS: Windows 11 Pro 25H2, build 26200.8246
Device: Lenovo ThinkPad X1 Carbon Gen 11, i7-1365U, 32GB RAM
Claude Desktop: Microsoft Store build (package family Claude_pzs8sxrjxfjjc)
Chrome: latest (just updated)
Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn (Chrome Web Store)
Plan: Max

Client side verified clean

Native messaging manifest registered at HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension
Manifest points to existing chrome-native-host.exe at the expected LocalCache\Roaming\Claude\ChromeNativeHost\ path
Installed extension ID matches one of the three allowed_origins in the manifest
Single machine, single extension install, no Chrome Canary or other Chromium variants
Supported 4.5 model selected, per-conversation connector toggle enabled
Restart sequence performed: Claude Desktop fully exited from system tray, confirmed killed in Task Manager, Chrome fully closed, Desktop relaunched first then Chrome
Cycled sign-in methods (Google then email magic link) across Desktop, extension, and claude.ai
Cleared cache, uninstalled and reinstalled both Desktop and extension

Behaviour
Settings > Browser Use > Connected browsers shows "No browsers connected". Recheck has no effect. Two support tickets via in-app chat help submitted weeks apart, no response on either.
This matches the symptom and elimination pattern in #44541 and #36626, which suggests the bridge OAuth verification failing for this account regardless of platform. Happy to provide logs from %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\ if useful.

[Claude in Chrome] Bridge error: OAuth token forbidden (403) — missing scope or org access [Claude in Chrome] Bridge connection closed (code: 1008, duration: 0ms) […](#)

If you are using Claude Code cli, could you run /login that should retrieve a fresh token with the correct scope.

> [Claude in Chrome] Bridge error: OAuth token forbidden (403) — missing > scope or org access > [Claude in Chrome] Bridge connection closed (code: 1008, duration: 0ms) > […](#) If you are using Claude Code cli, could you run /login that should retrieve a fresh token with the correct scope.

I believe this advice is specifically for Claude Code CLI users — running /login in the terminal to refresh their token. However, I'm using Cowork mode (the desktop app), which has a different authentication flow than the CLI.

Same issue, this needs fixing, ffs

Same issue here too. Cant retrograde, the versions on uptodown are not compatible with cowork...

Potential root cause: Third-party antivirus Web Shield blocking the connection

Found a fix that may help others. In my case the issue wasn't a Cowork software bug — it was AVG AntiVirus Web Shield intercepting and blocking the connection between the Chrome extension and Cowork.

How to diagnose:

1. Run netstat -ano | findstr LISTEN in PowerShell and cross-reference with Claude process IDs using Get-Process | Where-Object {$_.Name -like "*claude*"}
2. If no ports appear listening for any Claude process, the local server appears dead — but the real cause may be AV interception upstream

Fix:
Add exceptions in your antivirus web shield for:

• claude.ai
• anthropic.com

After adding those exceptions and re-enabling Web Shield, the connection was restored immediately. It's worth checking if you're running AVG, Kaspersky, Norton, Bitdefender or any AV with web traffic inspection before assuming it's a Cowork regression.

Off the back of @RichardQslice suggestion i ran some experiments with Norton AV and have concluded similar.

The HTTPS scanning feature is blocking the connection.

I had hit this problem when i was trying to the google-analytics-mcp.

I believe this is related to the upgrade in python (3.13+) where the flag VERIFY_X509_STRICT, which requires CA certificates to have their Basic Constraints extension marked as critical is the root cause, due to AV platforms Certs as part of HTTPS scanning don't meet that requirement and silently fails.

At present i turned HTTPS scanning off, not sure what the perm solution is.

same problem, how can i fix iti?

hello, in working with claude in windows and i cannot do cowork with chrome. How can i fix it? Is there somehow?

I can confirm that Norton's Web Shield / HTTPS Scanning is the root cause of the "Claude in Chrome is not connected" error in Cowork mode.

Disabling Web Shield immediately restored the connection between Cowork and the Chrome extension. No other changes needed.

This aligns with the technical explanation already posted here: Python 3.13+'s VERIFY_X509_STRICT flag rejects Norton's HTTPS scanning certificates because they don't have the Basic Constraints extension marked as critical, causing a silent connection failure.

Workaround: Disable HTTPS Scanning in Norton temporarily to confirm this is your issue. For a more targeted fix, try adding api.anthropic.com and claude.ai as URL exceptions in Norton's Safe Web settings, or add Claude Desktop as a trusted application under Firewall → Program Rules.

Hope this helps other Norton users hitting the same wall.

Confirming the Norton HTTPS scanning workaround on Windows 11.

Setup: Windows 11 corporate, Claude Desktop (MSIX install),
Chrome extension v1.0.70, Norton Small Business with default
web protection enabled.

Fix that worked: in Norton → Paramètres → Navigation web
sécurisée → Exclusions, added these 4 domains (both HTTP and
HTTPS variants auto-created by Norton):

• claude.ai
• anthropic.com
• claudeusercontent.com
• bridge.claudeusercontent.com

Connection restored immediately after closing/reopening Chrome
and Cowork. mcp__Claude_in_Chrome__list_connected_browsers now
returns a valid Browser entry where it returned "not connected"
permanently before.

Confirms @Gavin-Attard-120feet's diagnosis: Norton's HTTPS
scanning silently breaks the WebSocket bridge handshake. Worth
adding to official troubleshooting docs.

Update (May 2026) — Issue persists for some; my own update went clean

After investigating ~20 related threads, sharing findings for others hitting this.

The error message "Claude in Chrome is not connected" covers at least 6 distinct failure modes:

1. Native messaging path stale after Desktop update (macOS)

The manifest at ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json can point to a non-existent binary after an update. Check that the path field still resolves to a real file.

2. OAuth token rejection at the WebSocket bridge

wss://bridge.claudeusercontent.com returns code 1008 ("Invalid token or user mismatch") or 403 ("missing scope"). Server-side issue — no reliable client-side fix. Visiting https://clau.de/chrome/reconnect and re-pairing sometimes resolves it.

3. API key mode silently blocking Chrome

If you authenticated via API key instead of a subscription login, Chrome integration won't work. Fix: sign out, go to /login, and choose the subscription option.

4. Chrome 147+ service worker not auto-initialising

Click the extension icon manually before starting a Cowork session to wake the service worker.

5. Antivirus HTTPS scanning (Windows)

Multiple Windows users confirmed that third-party AV intercepting HTTPS traffic breaks the bridge TLS handshake. Disabling HTTPS scanning resolved it for them.

6. VM-to-host bridge broken (Windows / Cowork)

Unix socket inside the Cowork VM not being created on session start.

---

My outcome: Updated from 1.1.8629 → 1.7196.1 on macOS with extension v1.0.70. Connection survived the update intact — Chrome returned live tabs immediately post-update. The NativeMessagingHosts manifest was unchanged by both the Chrome and Claude Desktop updates.

Hi All

5 worked for me and I posted my solution on github

Regards

Mehdi

Envoyé à partir de Outlook pour iOS<https://aka.ms/o0ukef>
________________________________
De : Julian M. @.*>
Envoyé : Sunday, May 17, 2026 6:43:02 PM
À : anthropics/claude-code @.*>
Cc : Mehdi BEN DALY @.>; Comment @.>
Objet : Re: [anthropics/claude-code] [BUG] Claude in Chrome + Control Chrome Failures in Cowork Mode (Issue #48806)

Attention CBA Expert e-mail users: This email originated from outside of CBA Expert and most likely was not sent by a CBA Expert employee or officer. Please be extra vigilant when opening attachments, clicking links or acting on any instructions contained in this email. Please report any concerns immediately to your Manager.

[https://avatars.githubusercontent.com/u/13994516?s=20&v=4]julian-molina left a comment (anthropics/claude-code#48806)<https://github.com/anthropics/claude-code/issues/48806#issuecomment-4471876400>
Update (May 2026) — Issue persists for some; my own update went clean

After investigating ~20 related threads, sharing findings for others hitting this.

The error message "Claude in Chrome is not connected" covers at least 6 distinct failure modes:

1. Native messaging path stale after Desktop update (macOS)

The manifest at ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json can point to a non-existent binary after an update. Check that the path field still resolves to a real file.

1. OAuth token rejection at the WebSocket bridge

wss://bridge.claudeusercontent.com returns code 1008 ("Invalid token or user mismatch") or 403 ("missing scope"). Server-side issue — no reliable client-side fix. Visiting https://clau.de/chrome/reconnect and re-pairing sometimes resolves it.

1. API key mode silently blocking Chrome

If you authenticated via API key instead of a subscription login, Chrome integration won't work. Fix: sign out, go to /login, and choose the subscription option.

1. Chrome 147+ service worker not auto-initialising

Click the extension icon manually before starting a Cowork session to wake the service worker.

1. Antivirus HTTPS scanning (Windows)

Multiple Windows users confirmed that third-party AV intercepting HTTPS traffic breaks the bridge TLS handshake. Disabling HTTPS scanning resolved it for them.

1. VM-to-host bridge broken (Windows / Cowork)

Unix socket inside the Cowork VM not being created on session start.

________________________________

My outcome: Updated from 1.1.8629 → 1.7196.1 on macOS with extension v1.0.70. Connection survived the update intact — Chrome returned live tabs immediately post-update. The NativeMessagingHosts manifest was unchanged by both the Chrome and Claude Desktop updates.

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/48806#issuecomment-4471876400>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/CCJGPVTBZHTOSCNVRGPASDL43H22NAVCNFSM6AAAAACX2ZH4KSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINZRHA3TMNBQGA>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID: @.***>

Closing for now — inactive for too long. Please open a new issue if this is still relevant.