VSCode's Remote SSH Agent Behaves an Awful Lot Like a RAT

Fly.io wanted to plug into VSCode’s remote-editing-over-SSH flow, largely because so many developers—and the LLM-powered VSCode forks now common in agentic coding—rely on it. That interest led them to inspect how the feature actually works, and what they found unsettled them. The natural comparison is Emacs’ Tramp, which extends the editor to a remote host by simply issuing Bourne shell commands over an existing SSH session, living off the land. VSCode takes a far heavier approach.

Instead of leaning on tools already present, VSCode pushes a Bash stager to the remote machine that downloads a full agent, including a bundled Node binary. That agent runs over port-forwarded SSH and opens a WebSocket back to the local VSCode frontend. Through it, the remote process can roam the filesystem, edit arbitrary files, spawn its own shell PTYs, and persist itself across sessions—a capability set that maps uncomfortably onto the profile of a remote access trojan, a point the author gestures at without naming outright.

The practical warning is about blast radius: this is a lot of trust to extend to a remote endpoint. The author is wary of using it on shared dev servers and adamant it has no place touching production during an incident. The broader context is that agentic LLM workflows want a clean, disposable Linux instance to iterate on—precisely so a model with ‘boundary issues’ can’t wreck a real machine—which makes understanding what VSCode’s agent can do on the far end more than academic.