Claude Desktop (Cowork): TLS verification failure on bridge.claudeusercontent.com — bundled Node CA bundle issue on Windows 11 [regression ~1 week]

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?

Claude Desktop (Cowork mode) on Windows 11 cannot establish the WebSocket bridge to bridge.claudeusercontent.com. As a result, all mcp__Claude_in_Chrome__* tools return "Claude in Chrome is not connected", even though:

• The Claude in Chrome Chrome extension is installed, enabled, signed in
• The standalone extension works correctly on claude.ai (RSVP onboarding challenge completes successfully)
• Cowork reports the "Claude in Chrome" MCP server as "connected"
• The Windows registry entry for the native messaging host is present and valid

The underlying error is a TLS certificate verification failure on every bridge connection attempt. From main.log:

[Claude in Chrome] Connecting to bridge: wss://bridge.claudeusercontent.com/chrome/<orgId>
[Claude in Chrome] Bridge WebSocket error after 84ms: unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca
[Claude in Chrome] Bridge connection closed (code: 1006, duration: 0ms)

This loops indefinitely. I verified there is no MITM / SSL inspection on this machine: opened https://bridge.claudeusercontent.com in Chrome, the certificate is the legitimate Google Trust Services (WE1) issued cert with no corporate / AV root CA in the chain.

Filing this on the claude-code repo because it's the only public Anthropic repo that touches the shared bridge infrastructure — but the bug surfaces inside Claude Desktop / Cowork, not Claude Code (Claude Code is uninstalled on this machine).

What Should Happen?

Claude Desktop should successfully open the WebSocket bridge to bridge.claudeusercontent.com, allowing mcp__Claude_in_Chrome__* tools (list_connected_browsers, navigate, get_page_text, etc.) to operate against the local Chrome instance.

Either the bundled Node runtime in Claude Desktop should trust the legitimate Google Trust Services certificate out of the box, or there should be a documented user-side mechanism (env var, settings file) to point it at the OS certificate store.

Error Messages/Logs

From %APPDATA%\Claude\logs\main.log:

[Claude in Chrome] ensureConnected called, connected=false, authenticated=false, wsState=3
[Claude in Chrome] Not connecting, starting connection...
[Claude in Chrome] Connecting to bridge: wss://bridge.claudeusercontent.com/chrome/<orgId>
[Claude in Chrome] Bridge WebSocket error after 84ms: unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca
[Claude in Chrome] Bridge connection closed (code: 1006, duration: 0ms)
[Claude in Chrome] No longer connecting, giving up

Secondary recurring error on Claude Desktop startup (file is locked by Chrome's already-running native host process — likely cosmetic, the original copy already exists):

[Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile 'C:\Program Files\WindowsApps\Claude_1.6608.2.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe' -> 'C:\Users\<user>\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'
[Chrome Extension MCP] Native host sync complete

Certificate inspection of bridge.claudeusercontent.com via Chrome (proves no MITM):

Issued To:   claudeusercontent.com
Issued By:   WE1 (Google Trust Services)
Validity:    2026-03-19 → 2026-06-17

Steps to Reproduce

1. Install Claude Desktop 1.6608.2.0 on Windows 11.
2. Install the "Claude in Chrome" browser extension in Chrome, sign in, complete the onboarding challenge on claude.ai to confirm the extension itself works.
3. Open Claude Desktop, start a Cowork conversation.
4. Ask Claude to do anything that uses the Chrome MCP, e.g. "open google.com in chrome".
5. Observe Cowork reports "Claude in Chrome is not connected".
6. Open %APPDATA%\Claude\logs\main.log and grep for "Bridge WebSocket error" — the TLS verification failure appears on every bridge attempt.

Additional context / things already ruled out:

• Claude Code was previously installed and has been uninstalled; behavior unchanged.
• Norton 360 (the only AV on this machine) was tested with Auto-Protect and Smart Firewall both disabled for 15 min; behavior unchanged.
• No corporate SSL-inspection software is installed (no Zscaler / Forcepoint / Cisco / Netskope / Palo Alto / FortiClient / Pulse / Ivanti).
• Setting user-level env var NODE_OPTIONS=--use-system-ca and restarting Claude Desktop and Chrome had no effect — the bridge still fails with the same TLS error.
• claude.ai cookies cleared and re-authenticated; service workers unregistered; Claude Desktop reinstalled.
• Windows registry has a single valid entry under HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension pointing to a valid manifest.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

~1 week before 2026-05-12 (early May 2026). Auto-updates enabled; exact prior Claude Desktop version unknown.

Claude Code Version

N/A — Claude Code is uninstalled. Bug is in Claude Desktop 1.6608.2.0 (Cowork mode).

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Regression timing: Chrome bridge was working correctly approximately 1 week before 2026-05-12 (early May 2026) on the same Windows 11 machine, same Norton 360 setup, same network. It stopped working with no user-side change — auto-updates are enabled, so a recent Claude Desktop release is the most likely culprit.

This makes it likely a regression introduced in a Claude Desktop build shipped in the last ~7 days (relative to 2026-05-12), not a long-standing environmental issue on this machine.

I can provide:

• Full main.log (7.6 MB) on request
• cowork_vm_node.log
• claude.ai-web.log
• Output of Get-ChildItem Cert:\LocalMachine\Root to confirm no unusual root CAs
• Screenshot of bridge.claudeusercontent.com Chrome certificate viewer