Windows host, exec server: after a network drop the window loops "reconnect, drop after 20 s" with write ENOTSUP in _sendSocketToExtensionHost #11947

Is there an existing issue for this bug?

• I have searched the existing open issues and found none that apply.
• Related, but a different cause: Cannot re-connect to windows host #11403 and Windows host - every reconnect (Reload Window) fails with CodeError(CommandFailed { command: "bash", output: "program not found" }) #11911 (reconnect to a Windows host fails with "bash program not found", which comes from remote.SSH.defaultExtensions). This one has no bash error; the extension host never receives the new connection.

Required Troubleshooting Steps

• I have read and performed the troubleshooting steps
• I have tried both values of remote.SSH.useLocalServer (ran with false; not tried with true for this failure)
• My issue was not covered in the Tips and Tricks
• Complete Remote-SSH log: the client log of the failing session was not kept. The host side is below. I can reproduce and attach a full client log if needed.

[Optional] Diagnose with Copilot

I did not ask the @remote-ssh participant for help.

In step 2 of the troubleshooting wiki, what was the result of running the generated SSH command verbatim outside of VS Code?

I could successfully SSH to the remote machine.

Remote-SSH Log

Host: ~\.vscode-server\data\logs\<session>\remoteagent.log (server commit 6d62b1d5dace93a33b3a6d3eca1317bd5e15bcb1, exec server mode):

2026-11-03 11:33:36.460 [info] [<unknown>][94264095][ManagementConnection] The client has disconnected gracefully, so the connection will be disposed.
2026-11-03 11:33:36.743 [error] [<unknown>][00854f31][ExtensionHostConnection] <9584> Extension Host Process had an error
2026-11-03 11:33:36.743 [error] Error: write ENOTSUP
    at target._send (node:internal/child_process:917:20)
    at target.send (node:internal/child_process:792:19)
    at qu._sendSocketToExtensionHost (file:///C:/Users/<user>/.vscode-server/cli/servers/Stable-6d62b1d5dace93a33b3a6d3eca1317bd5e15bcb1/server/out/server-main.js:79:23782)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)

The same error appears 33 times in two episodes (7 times at 11:33, 26 times at 12:42). On the client, renderer.log showed the socket timing out with reason: unacknowledgedMessage about 20 s after each reconnect.

Expected Behavior

After the network comes back, the window reconnects to the running extension host and the session in it (Claude Code, terminals) survives.

Actual Behavior

The window reconnects, the server fails to hand the new connection to the running extension host (write ENOTSUP), and the window drops the connection again about 20 s later. This repeats until Reload Window, which starts a new extension host, so everything running in the old one is lost.

Steps To Reproduce

1. Windows 11 Home host with OpenSSH Server; remote user is a regular (non-admin) account. Client: macOS, Remote-SSH 0.128.0, remote.SSH.useExecServer at its default (true), remote.SSH.useLocalServer: false.
2. Open a Remote-SSH window to the host and leave an extension running in it.
3. Drop the client's connection for a minute or two (lose Wi-Fi, or kill the ssh process) and let the window reconnect.
4. The host log shows write ENOTSUP from _sendSocketToExtensionHost; the window drops again after ~20 s, in a loop.

Anything else?

In exec server mode the server on Windows is started with --socket-path=\\.\pipe\code-..., so connections arrive over a named pipe. Node on Windows can only pass TCP handles between processes (child_process.send with a handle), which would explain ENOTSUP when the server passes a reconnected socket to the extension host. That's our reading of the stack, not checked in the source.

Workaround: "remote.SSH.useExecServer": false. Remote-SSH then starts the server with --port 0 (TCP). With it, cutting the ssh of an open window gave a reconnect in 7 s on the first try, zero ENOTSUP, and the same extension host.