[BUG] Remote Control reports "/rc active" while its input channel is silently dead under local TLS interception (Norton 360 SSL scanning)

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?

Local TLS interception by antivirus/endpoint software silently kills Remote Control's inbound (input) channel, while the CLI continues to report /rc active and the web/mobile client shows a healthy, live session.

Messages sent from claude.ai/code or the Android app are accepted, rendered in the thread, and then spin forever. They never reach the local session. There is no error, no warning, and no degraded state anywhere — on either end.

Root cause on my machine: Norton 360 (v26.5.10994.2525, C:\Program Files\Norton\Suite\wsc_proxy.exe) performs SSL/TLS scanning, terminating and re-signing every TLS connection Windows processes make to api.anthropic.com. Ordinary API traffic and response streaming pass through fine — Claude Code is fully functional — but Remote Control's long-lived inbound channel does not survive the interception.

I believe this is the underlying cause of #66556 (same symptom, same Windows 11 build, no root cause identified there), and plausibly of several other "Remote Control input does nothing" reports.

I am filing this as a product defect, not a support request. Remote Control advertises itself as active in a context where its input half provably cannot work. That is the bug. An interception-aware error ("Remote Control input channel unavailable — TLS connection to api.anthropic.com is being intercepted by <issuer>") would have saved hours; the silent infinite spinner sent me through auth modes, ANTHROPIC_BASE_URL, org policy, session IDs, child-session theories and corporate proxy configuration before I thought to look at the certificate.

What Should Happen?

Either of:

1. Detect and report. When the inbound channel cannot be established or is being terminated by a MITM proxy, surface it: refuse to report /rc active, and print an actionable error naming the intercepting issuer (the CLI can read it off the TLS handshake it is already performing).
2. Fail the send loudly. If a remote message is accepted by the API but not acknowledged by the local session within a timeout, the web/mobile client should say so ("session did not receive this message") rather than spinning indefinitely.

At minimum, claude doctor should flag a non-public certificate issuer on api.anthropic.com as a known-hostile condition for Remote Control.

Error Messages/Logs

None. That is the entire problem — there is no error anywhere.

Everything a user would normally check reports "healthy":

$env:HTTPS_PROXY / HTTP_PROXY / ALL_PROXY      -> empty
$env:ANTHROPIC_BASE_URL                        -> empty
netsh winhttp show proxy                       -> "Direct access (no proxy server)."
curl.exe -w "%{ssl_verify_result}" https://api.anthropic.com/   -> 0   (verify CLEAN)
CLI footer                                     -> "/rc active"
claude.ai/code                                 -> session listed, live, correct repo + PR badge

TLS verify comes back clean because the AV's root CA is trusted in the Windows certificate store. The only signal that anything is wrong is the certificate issuer:

$c=[Net.Sockets.TcpClient]::new('api.anthropic.com',443)
$s=[Net.Security.SslStream]::new($c.GetStream(),$false,{$true})
$s.AuthenticateAsClient('api.anthropic.com')
"Issuer: $(([Security.Cryptography.X509Certificates.X509Certificate2]$s.RemoteCertificate).Issuer)"
$s.Dispose(); $c.Close()

Issuer: CN=Norton Web/Mail Shield Root, O=Norton Web/Mail Shield,
        OU=generated by Norton Antivirus for SSL/TLS scanning

Steps to Reproduce

Controlled comparison — same account, same browser, same machine, same minute. The only variable is whether the TLS interception is in the path (WSL2 runs over a separate virtual NIC that Norton does not filter).

A. Windows (intercepted) — FAILS

1. claude in PowerShell, then /remote-control
2. Open the printed https://claude.ai/code/session_... URL in Chrome
3. Send "acknowledge this message"
4. Message renders in the thread, spinner runs indefinitely (observed >1m26s). The local terminal shows no reaction whatsoever — prompt stays idle, nothing queued. Pressing Esc locally changes nothing (this is not the #51267 TTY deadlock; the session is idle, not mid-turn).
5. Identical failure from the Android app.

Certificate issuer in this context: CN=Norton Web/Mail Shield Root (intercepted).

B. WSL2 Ubuntu (not intercepted) — WORKS

1. Install Node + Claude Code inside WSL, cd /mnt/c/<same repo>, claude
2. /remote-control, open the printed URL in the same Chrome
3. Send "test. acknowledge this input from chrome RC"
4. Message arrives immediately, Claude responds, response renders back in Chrome. Full round trip.

Certificate issuer in this context: C=US, O=Google Trust Services, CN=WE1 (genuine).

| Session | Issuer for api.anthropic.com | Remote input |
|---|---|---|
| Windows native | CN=Norton Web/Mail Shield Root | never arrives, infinite spinner |
| WSL2 Ubuntu | O=Google Trust Services, CN=WE1 | arrives, full round trip |

Environment

• Claude Code v2.1.207 (also reproduced on the same version pre-WSL)
• Windows 11 Pro 10.0.26200
• Plan: Claude Max (claude.ai OAuth; no ANTHROPIC_API_KEY, no Bedrock/Vertex, no ANTHROPIC_BASE_URL)
• Norton 360 v26.5.10994.2525 with SSL/TLS scanning active (default; Norton exposes no supported exclusion for it — see Norton Community "Where are SSL/TLS scanning settings in Norton 360", answer: "they don't offer you a way to STOP Norton using its own certificate")
• Clients tested: Chrome (desktop) and the Claude Android app — both fail identically on Windows, which correctly localizes the break to the host machine rather than either client.

Claude Model

Opus 4.8

Notes

Workaround for anyone hitting this: run Remote Control sessions from WSL, which the Windows AV filter does not intercept.

Given that Norton offers no way to exempt a host from SSL scanning, any Norton user on Windows currently has Remote Control silently broken with no diagnosable cause. That is likely a non-trivial population, and every one of them will experience it as "the feature just doesn't work."