Remote-control

Up!

Up

Up

I hit exactly this on Windows 11 Pro 10.0.26200 (CLI, not VSCode — so the bridge, not the extension, is at fault) and tracked down the root cause: local TLS interception by antivirus software.

In my case Norton 360 (v26.5, wsc_proxy.exe) performs SSL/TLS scanning, which terminates and re-signs every TLS connection Windows processes make to api.anthropic.com. Normal API traffic and streaming survive it — Claude Code works fine — but Remote Control's inbound (input) channel does not. Result is precisely what you describe: session active, valid link, messages sent from the web are silently ignored, no error anywhere.

Check whether this is your cause — note that every conventional check reports "healthy" (HTTPS_PROXY empty, netsh winhttp show proxy says "Direct access", and the TLS verify is clean, because the AV's root CA is trusted in the Windows store). The only thing that reveals it 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()

• Healthy: C=US, O=Google Trust Services, CN=WE1
• Intercepted: your AV vendor's name, e.g. CN=Norton Web/Mail Shield Root, OU=generated by Norton Antivirus for SSL/TLS scanning

Proof by controlled comparison (same account, same browser, same machine — WSL2 runs over a separate virtual NIC that the AV filter doesn't touch):

| 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 |

Workaround: run Remote Control sessions from WSL.

I've filed the underlying product defect separately (Remote Control reports /rc active while its input channel is provably dead, instead of surfacing an error): https://github.com/anthropics/claude-code/issues/76642

Confirmed: Norton 360 TLS interception — and a less drastic fix than WSL
Same symptoms as OP (VSCode extension, Windows 11): /remote session shows active, valid link, but messages from the web UI never arrive. No errors anywhere.

Following the diagnosis from the comment above, I confirmed the TLS interception with the PowerShell snippet:
Issuer: CN=Norton Web/Mail Shield Root, O=Norton Web/Mail Shield, OU=generated by Norton Antivirus for SSL/TLS scanning
So Norton 360's HTTPS scanning was re-signing the connection to api.anthropic.com, which kills Remote Control's inbound channel while everything else keeps working.

Fix without WSL — targeted Web Shield exception:

Norton 360 → Settings → Web Shield module settings (not the global file exclusions list — that one only accepts files/folders and won't help).
Inside the Web Shield module, open its own Exceptions list (near the "Enable HTTPS scanning" option).
Add:

https://api.anthropic.com/

Re-run the PowerShell check — the issuer should now be O=Google Trust Services, CN=WE1. If Norton still shows up, reboot (the TLS proxy can cache connections) and re-test.
Restart VSCode and start a new /remote session before concluding (a session established before the exception may still use the intercepted channel).

Result: Remote Control works end-to-end, and Norton's HTTPS scanning stays enabled for everything else. No need to disable HTTPS scanning globally or switch to WSL.

Tested on Norton 360 (new Norton/Avast engine, "Web/Mail Shield"), Windows 11, VSCode extension.

This also reinforces that the underlying product defect (#76642 — session reported active while the input channel is dead, with no surfaced error) is worth fixing: three of us hit this silently now.