›_ Claude Code Issues
Claude Code Issues / #77494

Desktop dispatch bridge fails behind Norton SSL inspection - ignores NODE_EXTRA_CA_CERTS, CLAUDE_CODE_CERT_STORE, and --use-system-ca

Open 💬 0 comments Opened Jul 14, 2026 by LBritainDec

Bug report: Desktop dispatch bridge fails behind Norton SSL inspection — ignores all CA trust settings

Summary

The Claude Desktop app's Cowork/Dispatch sessions-bridge cannot connect when Norton antivirus (Norton Security Ultra) performs SSL/TLS inspection. The bridge transport fails repeatedly with:

[error] [sessions-bridge] Failed to connect transport for session cse_...:
unable to verify the first certificate; if the root CA is installed locally,
try running Node.js with --use-system-ca

As a result the device shows as "asleep" in the mobile app's Dispatch screen even though the desktop app is running and Keep Awake is enabled. The bridge transport ignores every documented CA-trust mechanism, and there is no user-accessible way to make it trust the interception CA.

Environment

  • Claude Desktop 1.20186.9 (sideloaded MSIX from claude.ai/download, SignatureKind=Developer), embedded Node 24.17.0, bundled Claude Code 2.1.209
  • Windows 11 Home 10.0.26200
  • Norton Security Ultra with SSL/TLS scanning active ("Norton Web/Mail Shield Root" CA, present in the Windows LocalMachine Root store)
  • Updater log confirms app is on the latest version ([updater] Checking for updates → no update)

What works vs. what doesn't

  • Environment registration succeeds: POST /v1/environments/bridge → Environment registered (Chromium net stack trusts the Windows store).
  • The SDK bridge transport fails every retry: [transport:sdk] attaching SDK bridge session ... apiBaseUrl=https://api.anthropic.com → unable to verify the first certificate.

Workarounds attempted — all ignored by the bridge transport

  1. Norton's own mitigation: it sets NODE_EXTRA_CA_CERTS=C:\ProgramData\Norton\Antivirus\wscert.pem machine-wide; file verified to contain the correct root CA (thumbprint matches the store cert 5E6A5F4BB720EBC62A08745A0ADC21287ECEE070). Ignored.
  2. User env var NODE_EXTRA_CA_CERTS pointing at a freshly exported copy of the CA. Ignored.
  3. ~/.claude/settings.json → env: { "CLAUDE_CODE_CERT_STORE": "bundled,system", "NODE_EXTRA_CA_CERTS": ... } (the documented network-config fix). Bridge still fails.
  4. User env var NODE_OPTIONS=--use-system-ca (the remedy the error message itself suggests). Ignored.
  5. Full app quit/relaunch after each change. No effect.
  6. Norton UI reviewed exhaustively: no HTTPS-scanning toggle and no URL/domain exclusion exists in this product version, so the interception cannot be disabled per-domain on the AV side.

Expected behavior

The dispatch bridge transport should honor CLAUDE_CODE_CERT_STORE=bundled,system (or default to including the OS trust store, as Chromium already does elsewhere in the same app), or at minimum honor NODE_EXTRA_CA_CERTS/--use-system-ca.

Related issues

  • anthropics/claude-code#70394 (Desktop ignores NODE_EXTRA_CA_CERTS on Windows MSIX)
  • anthropics/claude-code#63470 (Remote Control fails silently under HTTPS-scanning AV)
  • anthropics/claude-code#58388 (previous bridge TLS verification failure)

Impact

Dispatch is completely unusable for consumers running Norton/Avast-family antivirus (which sets up SSL inspection by default), and the mobile app's "asleep" status gives no hint of the real cause.

View original on GitHub ↗