VS Code Remote SSH, set up and unstuck

Remote - SSH — ms-vscode-remote.remote-ssh, from Microsoft, also in the Remote Development pack — opens an SSH connection to a machine, installs a small VS Code Server into ~/.vscode-server there, and from then on runs everything that touches files on that machine: the file tree, language servers, the debugger, extensions that need the code, and every integrated terminal. Your local VS Code becomes a window onto it. The server runs as the user you signed in as; VS Code installs and updates it to match the client’s version.

Locally: an OpenSSH-compatible ssh on the PATH — macOS and Linux have one, Windows 10 and 11 carry Microsoft’s as an optional feature. The host must be one the server runs on: 64-bit x86 Linux with glibc 2.28+, libstdc++ 3.4.25+ and kernel 4.18+ — Ubuntu 20.04+, Debian 10+, RHEL 8+, per the Linux prerequisites; ARM64 and 32-bit ARMv7 Linux, where some extensions ship x86-only native code; macOS 10.14+ with Remote Login on; or Windows 10 and Server 2016+ with the official OpenSSH Server. Alpine and other musl-based hosts are not supported over SSH. Microsoft recommends 2 GB of RAM and two cores; 1 GB is the floor.

One limit is worth understanding before you rely on the setup, because no setting removes it. Every integrated terminal in a Remote - SSH window is a process on the host, started by the VS Code Server for your window. VS Code’s persistent sessions cover two cases, and the terminal docs are exact: reload the window and the terminal reconnects to the same process; restart VS Code and its contents are restored but the process is relaunched. Relaunched, not resumed — the test run or the agent that was halfway through is not the one you get back.

Close the laptop for the afternoon and you are in the second case, or a third the docs promise nothing about: the connection drops, the window reconnects when it can, and what survived depends on the host’s sshd timeouts and how long the server waited. Anything that must keep running while you are not connected belongs in tmux, nohup, or a service on the host — not in the editor’s terminal. The phone does not help: vscode.dev is an editor, not a terminal. If you cannot open a port on the machine, Microsoft’s Remote Tunnels reach it through their service instead of SSH, with the same terminal limit.

The editor part of Remote - SSH is excellent and nothing here argues with it. The terminal part is where the shape runs out, exactly where agent work begins: a Claude Code refactor that takes an hour, a test loop, a build that finishes at 2am — jobs that must survive you leaving and want answering from wherever you are.

That is the job spawnd is shaped for, and it splits cleanly from the editor. One daemon on each host you own, dialing out — nothing listens on the host, no open ports, no VPN needed. A worker process on the host owns each session’s PTY, so a session survives the closed tab, the dropped connection, the laptop lid, and a daemon restart, scrollback intact. Any browser is the console, and on a phone it installs to the home screen as a web app; a new device is approved once against a short code. Your browser talks to each daemon peer-to-peer, end-to-end encrypted, and the server that introduces them never sees session content. Built-in shortcuts start Claude Code, Codex, OpenCode, or Aider in a real shell on the host, authenticated there as always; the workspace grid shows every session across every host, with an attention cue when an agent waits on a yes. Keep Remote - SSH for the editing; background agents defines the other half, and asks whose machine the agent is on.