Claude Desktop: Claude-in-Chrome bridge fails under corporate TLS inspection — bundled Node ignores NODE_EXTRA_CA_CERTS and NODE_USE_SYSTEM_CA (certificate signature failure on bridge.claudeusercontent.com)

What's Wrong?

Claude Desktop's Claude-in-Chrome bridge cannot connect on machines behind corporate TLS inspection, and the bundled Node runtime ignores every documented CA-trust mechanism, so there is no user-side way to fix it.

Our endpoint agent (Check Point Harmony SASE) intercepts and re-signs TLS for bridge.claudeusercontent.com. The corporate root CA is installed in the Windows certificate store, so Chrome, Edge, and .NET all validate the re-signed cert fine — the Claude in Chrome extension side works and holds an open connection to the bridge. Only Claude Desktop's Node-based bridge client rejects it:

[claude-in-chrome] Connecting to bridge: wss://bridge.claudeusercontent.com/chrome/<orgId>
[claude-in-chrome] Bridge WebSocket error after 91ms: certificate signature failure
[claude-in-chrome] Bridge connection closed (code: 1006, duration: 0ms)
[claude-in-chrome] Bridge reconnecting in 10125ms (attempt 5)

This loops indefinitely (1,400+ occurrences in main.log), and every mcp__claude-in-chrome__* tool returns "Claude in Chrome is not connected" even though the extension is installed, updated, and signed in with the matching account. WebFetch inside Desktop-launched Claude Code sessions fails with the same certificate signature failure on any inspected host.

CA-trust mechanisms tested — all ignored by the Desktop bridge:

| Mechanism | Verified present in the relaunched Desktop process? | Bridge result |
|---|---|---|
| NODE_EXTRA_CA_CERTS (HKCU env var → PEM bundle containing both corporate roots) | set in HKCU\Environment | still fails |
| NODE_USE_SYSTEM_CA=1 (HKCU env var, set via setx, full app restart) | yes — confirmed inherited by the new process | still fails |
| Corporate root in Windows trust store (LocalMachine\Root + CurrentUser\Root) | yes | still fails |

The NODE_USE_SYSTEM_CA=1 case is the decisive one: the variable demonstrably reached the freshly restarted Desktop process's environment, and the very next bridge attempts still failed with certificate signature failure.

Closely related: #58388 (same failure signature on Windows 11, auto-closed as inactive — that reporter had no MITM, suggesting a CA-handling bug in the bundled runtime; this report is the corporate-TLS-inspection variant with the trust-mechanism matrix above).

What Should Happen?

Claude Desktop's bridge WebSocket client should trust certificates the OS trusts — i.e. honor the Windows certificate store (Node's --use-system-ca / NODE_USE_SYSTEM_CA) or NODE_EXTRA_CA_CERTS, or expose a documented setting for a custom CA bundle. Chrome connects to the same bridge host on the same machine without issue; only the Desktop side of the pair fails.

Enterprises cannot always get *.claudeusercontent.com added to their inspection-bypass list quickly (that is the only current workaround, and it requires IT/security approval).

Steps to Reproduce

1. Windows machine with an endpoint TLS-inspection agent (here: Check Point Harmony SASE) that re-signs bridge.claudeusercontent.com, with the corporate root CA installed in the Windows trust store.
2. Install Claude Desktop + the Claude in Chrome extension, sign both into the same account. Confirm the extension itself works.
3. In a Claude Desktop / Claude Code session, call any claude-in-chrome tool (e.g. list_connected_browsers).
4. Observe "Claude in Chrome is not connected"; %APPDATA%\Claude\logs\main.log shows the certificate signature failure loop.
5. Set NODE_USE_SYSTEM_CA=1 and/or NODE_EXTRA_CA_CERTS user-wide, fully restart Claude Desktop, repeat — no change.

Environment

• Claude Desktop 1.25927.0.0 (Microsoft Store / MSIX package)
• Windows 11 Enterprise 10.0.26100
• Chrome 140.0.7339.185, Claude in Chrome extension 1.0.84
• TLS inspection: Check Point Harmony SASE endpoint agent (inline; interception active on any network, including home Wi-Fi)

Is this a regression?

Unclear — environmental trigger (interception of this domain began mid-July 2026 per certificate issue dates), but #58388 reported the same failure signature without any MITM in May 2026.