Remote-control

[cadjeenail-netizen]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Le /remote control ne fonctionne pas dans l'extension VSCode. Quand j'utilise /remote, j'obtiens un lien de session active. Je peux ouvrir ce lien dans le navigateur et envoyer des messages, mais Claude Code dans VSCode ne les reçoit pas — aucune réaction côté session.

What Should Happen?

Les messages envoyés depuis l'interface web /remote devraient être relayés en temps réel vers la session Claude Code active dans VSCode, comme si c'était un message normal.

Error Messages/Logs

Aucun message d'erreur visible. La session /remote s'affiche comme active avec un lien valide, mais les messages entrants sont silencieusement ignorés.

Environnement :
- Extension VSCode Claude Code
- OS : Windows 11 Pro 10.0.26200

Steps to Reproduce

1. Ouvrir Claude Code dans l'extension VSCode (Windows 11)
2. Taper /remote dans la conversation
3. Claude Code génère un lien de session active
4. Ouvrir le lien dans un navigateur web
5. Envoyer un message depuis l'interface web
6. Observer que Claude Code dans VSCode ne reçoit pas le message et ne répond pas

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.167

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

No response

[Blackychan25]

Up!

[FilipeVeber]

Up

[bartanderson]

Up

[JuergGood]

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): #76642

[Blackychan25]

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.