Problem
On Windows, when VS Code forks (Windsurf, Antigravity) use coder ssh --stdio as an SSH ProxyCommand, a visible console window is created for coder.exe. Closing that window kills the SSH connection.
This happens because coder.exe is built as a console subsystem application. When the parent process (ssh.exe) doesn't suppress window creation (via CREATE_NO_WINDOW), Windows allocates a new visible console for the child. Stock VS Code's Remote SSH extension avoids this by spawning ssh.exe with CREATE_NO_WINDOW, but Windsurf and Antigravity do not.
The fix cannot come from the vscode-coder extension side — it only writes the ProxyCommand string into SSH config and doesn't control process creation flags.
Suggested Fix
When --stdio is passed to coder ssh, the CLI only needs stdin/stdout piping and never uses interactive console I/O. On Windows, the binary could call FreeConsole() early in the --stdio path, or be built with -H windowsgui for the Windows target so no console is allocated at all.
Related
Problem
On Windows, when VS Code forks (Windsurf, Antigravity) use
coder ssh --stdioas an SSHProxyCommand, a visible console window is created forcoder.exe. Closing that window kills the SSH connection.This happens because
coder.exeis built as a console subsystem application. When the parent process (ssh.exe) doesn't suppress window creation (viaCREATE_NO_WINDOW), Windows allocates a new visible console for the child. Stock VS Code's Remote SSH extension avoids this by spawning ssh.exe withCREATE_NO_WINDOW, but Windsurf and Antigravity do not.The fix cannot come from the vscode-coder extension side — it only writes the
ProxyCommandstring into SSH config and doesn't control process creation flags.Suggested Fix
When
--stdiois passed tocoder ssh, the CLI only needs stdin/stdout piping and never uses interactive console I/O. On Windows, the binary could callFreeConsole()early in the--stdiopath, or be built with-H windowsguifor the Windows target so no console is allocated at all.Related