Fly.io’s Thomas Ptacek went looking at how VS Code does remote editing over SSH, because the team wanted to run closed-loop coding agents on disposable Linux instances instead of developer laptops. He expected something in the spirit of Emacs Tramp. What he found on the remote side was a different category of thing.
Tramp asks almost nothing of the remote machine — an interactive shell that can run Bourne commands, and it lives off the land from there. VS Code installs:
- A Bash snippet stager runs on the remote host and downloads an agent, including a binary installation of Node
- The agent runs over port-forwarded SSH and opens a WebSocket connection back to your local VS Code front end
- Over that connection the protocol can wander around the filesystem, edit arbitrary files, launch its own shell PTY processes, and persist itself
That capability list has an obvious security-world name, and Ptacek deliberately withholds it — saying it out loud “wouldn’t be fair to VSCode.” His actual recommendations are more measured:
- Be a little nervous about letting people remote-edit on dev servers
- Be apoplectic if it happens during an incident on something in production
- Notice that persistence is the sharp edge — the agent is not bounded by the session that installed it
The useful reframing is that “remote editing” quietly changed meaning. It used to be a client reaching into a host over a channel that already existed; now it is a deployment of a self-updating, network-reachable process with write access and a shell on the host. Point your editor at a machine and you have deployed to it.
Worth saying plainly: this is a short opinion piece from an interested party, not a study. Fly’s own integration didn’t need any of the agent machinery, which is why Ptacek says the whole thing “doesn’t matter in any kind of deep way” — he just thought people should know.