[BUG] Dispatch shows "desktop appears offline" behind TLS-inspecting AV — sessions-bridge Node transport does not use the system CA store

Summary

On a machine where an antivirus performs HTTPS scanning (here: Avast Free Antivirus 26.7.11086.3745, "Avast Web/Mail Shield Root" installed into the Windows trust store), Dispatch permanently reports "Desktop appears offline. Will run when it reconnects."

The root cause is a certificate-verification failure in the sessions-bridge Node transport. The UI surfaces this only as "offline", with no indication that TLS verification failed — which makes it indistinguishable from the server-side relay bugs, and effectively undiagnosable without reading main.log.

Environment

| | |
|---|---|
| Claude Desktop | 1.44121.4.0 (x64, MSIX / Microsoft Store package) |
| Claude Code (bridged SDK) | 2.1.258 |
| OS | Windows 11 Pro 26100 |
| Plan | Max |
| Antivirus | Avast Free Antivirus 26.7.11086.3745, HTTPS scanning enabled |

Session IDs are redacted below as <SESSION-A>.

Actual behaviour

sessions-bridge retries roughly every 16 seconds and fails every time:

08:22:33 [info]  [sessions-bridge] Connecting transport for session <SESSION-A>
08:22:33 [info]  [transport:sdk] attaching SDK bridge session <SESSION-A> (apiBaseUrl=https://api.anthropic.com)
08:22:33 [error] [sessions-bridge] Failed to connect transport for session <SESSION-A>:
                 unable to verify the first certificate; if the root CA is installed locally,
                 try running Node.js with --use-system-ca

Confirmed interception — chain presented for api.anthropic.com:

LEAF Subject : CN=api.anthropic.com
LEAF Issuer  : CN=Avast Web/Mail Shield Root, O=Avast Web/Mail Shield,
               OU=generated by Avast Antivirus for SSL/TLS scanning

The Avast root is trusted by Windows (present in both LocalMachine\Root and CurrentUser\Root), but the bundled Node runtime uses its own CA bundle and rejects it.

The revealing detail

The failure is partial, which is why the desktop looks half-alive:

• wss://bridge.claudeusercontent.com/... connects fine and reports remote-control bridge_state: "connected" — this path uses Electron's net stack, which does consult the Windows certificate store.
• https://api.anthropic.com via the SDK adapter fails — this path uses Node's TLS with the bundled CA bundle, which does not.

So the app reports a connected bridge while Dispatch is entirely non-functional.

Suggested fixes

1. Run the Node side with --use-system-ca (or set NODE_EXTRA_CA_CERTS from the OS trust store) so both transports agree on trust. The error message already suggests this — the app simply never applies it.
2. Surface the real error in the UI. "Desktop appears offline" is actively misleading for a TLS failure. Something like "Couldn't verify a secure connection to api.anthropic.com — a security product may be inspecting HTTPS traffic" would let users self-diagnose in seconds.
3. Consider a startup check that detects a non-public issuer on the API endpoint and warns once.

Workaround

Excluding api.anthropic.com, *.anthropic.com and *.claudeusercontent.com from Avast's HTTPS scanning resolved it immediately — the chain returned to CN=WE1, O=Google Trust Services, C=US and Dispatch connected on the next app restart.

Why this may matter for the existing reports

Several open "desktop appears offline" reports (#45937, #45962, #49545, #63179, #68481) are attributed to a server-side relay issue. At least some may be this instead — the symptom in the UI is identical, and nothing distinguishes them without opening main.log. Worth asking affected users to grep their logs for unable to verify the first certificate.