Remote Control silently fails when HTTPS-scanning AV (e.g. Norton 360) intercepts TLS - Node rejects MITM cert chain

Open 💬 3 comments Opened May 29, 2026 by internationaldevelopment

Summary

On Windows machines running HTTPS-scanning antivirus (Norton 360 confirmed; applies broadly to Bitdefender, Kaspersky, ESET, etc.), Remote Control fails silently in the VS Code extension and fails loudly with a TLS error from the standalone CLI. The root cause is that the antivirus intercepts outbound TLS connections and substitutes its own intermediate cert. Node's bundled CA bundle doesn't include the AV root, so the cert chain is rejected.

The diagnostic challenge: in the VS Code extension, the failure is partial and indirect (desktop -> phone read sync works, but phone -> desktop messages silently drop), which looks like a queueing or routing bug. Only when running the CLI directly does the actual error surface:

Error: unable to verify the first certificate

Environment

  • OS: Windows 11 (26200)
  • Claude Code: VS Code extension v2.1.154 + system CLI v2.1.152
  • Anti-virus: Norton 360 with HTTPS scanning enabled (Norton's default)
  • Phone: Android, latest Claude mobile app

Symptoms -- VS Code extension

  • Remote Control session starts successfully on the desktop
  • Phone pairs via the URL / QR
  • Desktop -> phone direction works fully: phone sees current conversation, receives new desktop messages, sees activity indicators
  • Phone -> desktop direction silently broken: messages typed on phone appear sent normally; phone shows "working on a response" indicator; desktop session never receives the message
  • No visible error on either side
  • Surface symptoms look like #62734 and #34255 superficially, but neither fix applies

Symptoms -- CLI fallback (claude remote-control --verbose in PowerShell)

Error: unable to verify the first certificate

Phone shows "Remote Control connecting..." indefinitely (never completes handshake).

What did NOT fix it

  • Upgrading from 2.1.119 -> 2.1.152 (the 2.1.141 token-rotation fix is unrelated)
  • Pressing Esc on the desktop (workaround for #62734)
  • Generating a fresh Remote Control link
  • Restarting VS Code

What DID fix it

[Environment]::SetEnvironmentVariable("NODE_TLS_REJECT_UNAUTHORIZED", "0", "User")

Restart VS Code. Phone -> desktop sync works in the extension; CLI handshake completes; phone connects and bidirectional sync flows.

This disables TLS validation entirely, which is acceptable on personal machines where the AV is already MITM'ing TLS, but isn't ideal. The cleaner fix is to export the AV's intermediate cert from the Windows trust store, save it as PEM, and set NODE_EXTRA_CA_CERTS=<path>.

Why this is worth surfacing

  • The cause (HTTPS-scanning AV) is extremely common on Windows. Norton, Bitdefender, Kaspersky, ESET, Avast, AVG, Sophos -- most default to HTTPS scanning unless turned off.
  • The extension's surface symptom (silent half-broken Remote Control) looks like a Claude Code bug, not a TLS bug. Users with this AV setup are likely to file under "Remote Control broken" without realizing it's their AV layer.
  • Issues #62734 and #34255 may have TLS interception as a confounding cause in some reports.

Suggested actions

  1. Docs: add a Remote Control troubleshooting section about TLS interception with the env var fix.
  2. UX: surface the underlying TLS error in the extension when RC encounters cert issues, so users see "unable to verify the first certificate" instead of silent half-sync.
  3. Optional auto-detect: log a warning at extension startup if NODE_TLS_REJECT_UNAUTHORIZED=0 is set OR if a TLS handshake against api.anthropic.com fails with UNABLE_TO_VERIFY_LEAF_SIGNATURE.

Happy to provide additional logs / verbose output if useful.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗