Thomas Ptacek, one of the more respected voices in application security, has published a technical walkthrough of what actually happens when you hit "Remote-SSH" in VSCode. The finding is straightforward but consequential: unlike Emacs's Tramp, which piggybacks on existing shell commands already available on the remote host, VSCode downloads and installs a full agent — including a binary Node.js installation — onto the target machine. That agent persists, runs its own shell PTY processes, wanders the filesystem, edits arbitrary files, and communicates back to your local VSCode instance via port-forwarded WebSockets. Ptacek stops short of calling it malware, but the architecture he describes — stager downloads binary payload, payload phones home over an encrypted tunnel, payload has arbitrary file and process access, payload persists — maps uncomfortably well to a remote access tool. His euphemism is "murid in nature," which is a polite way of saying RAT. The context that makes this matter right now is the agentic coding loop. LLM-powered coding agents — Copilot, Cursor, Cline, and their successors — need a closed feedback loop: generate code, execute it, observe errors, iterate. Developers increasingly want that loop running on a remote machine, not their laptop, precisely because LLMs "have boundary issues" and will happily modify system configuration if you let them. The clean-slate remote instance is the safety boundary. But if the tool you use to connect to that instance deploys its own persistent agent with broad filesystem and shell access, the safety boundary has a large hole in it. Ptacek's disclosure comes from Fly.io's work on integrating their Fly Machines as remote development targets. They ultimately found they don't need to care about VSCode's SSH agent architecture for their integration, but the investigation surfaced the design regardless. The blog post is characteristically dry: "we had to learn this, and now you do too." The practical concern splits into two scenarios. On development servers, the risk is manageable but non-trivial — a persistent agent with shell access is attack surface you may not have accounted for in your threat model. On production systems during incidents, where engineers sometimes SSH in with VSCode for convenience, the risk profile changes sharply. An auto-deployed, persistent binary agent on a production box during an active incident is the kind of thing that makes security teams lose sleep. Microsoft's design choice is understandable from a product perspective: full agent deployment gives VSCode feature parity with local editing, including extensions, debugging, and terminal integration. Tramp's approach — living off the land with shell commands — is simpler but far more limited. The tradeoff is capability for attack surface, and Microsoft chose capability without making the security implications particularly visible to users. The broader pattern here is one worth tracking: as development tools become platforms for autonomous code execution via LLM agents, the implicit trust model of those tools matters enormously. VSCode is the dominant editor. Its remote SSH feature is widely used. The agent it deploys is not well-understood by most of its users. That gap between capability and comprehension is where security incidents breed.
