Security researcher Thomas Ptacek questions VSCode's Remote-SSH agent and its broad host access

What VSCode actually installs on a remote host

When you open a remote machine in VSCode over SSH, the editor does far more than run commands through your existing session. According to security researcher Thomas Ptacek, writing on the Fly.io blog in a post that reached the Hacker News front page, the Remote-SSH feature starts by running a small Bash stager on the target host. That stager downloads a complete agent — including a bundled, binary installation of Node.js — which then opens a WebSockets connection back to your VSCode window, carried through port-forwarded SSH.

Ptacek, who points to what he believes is the relevant source code, enumerates what the protocol on that connection can do: move around the remote filesystem, edit arbitrary files, launch its own shell processes on pseudo-terminals, and persist itself on the machine. The security industry, he notes, has a standard name for tooling with exactly this capability profile. He declines to state it outright, joking instead that the term is "murid" — a nod to the rodent family that includes rats, and a none-too-subtle reference to the RAT, or remote access trojan.

The contrast with Emacs Tramp

Ptacek anchors the post in a comparison with Tramp, the long-standing Emacs extension for remote editing. Tramp can extend Emacs to any host reachable through an interactive session where it can issue Bourne shell commands, typically over SSH; it works with what the connection itself provides. VSCode takes the opposite approach: rather than sending shell commands down the pipe, it deploys a resident service with its own runtime.

Ptacek's unease stems from that design. A persistent component that can write files anywhere, spawn processes, and keep itself installed is a different proposition from a shell session that ends when you disconnect.

Why Fly.io was looking at this at all

The post grew out of practical work. Fly.io wants its fast-starting Linux machines wired into the remote-editing flow that VSCode users — and, increasingly, users of LLM-centric VSCode forks — already inhabit. Ptacek's argument is that LLM coding agents are most effective in a closed loop, where generated code is executed and the resulting errors are fed back for another pass.

That loop, he contends, should not run on a developer's laptop, because an agent will happily reconfigure the machine it lives on rather than confining itself to the project at hand. A disposable remote instance is the safer venue. Notably, the team found it could connect VSCode to a Fly machine without engaging the standard agent machinery at all, and the post is explicitly framed as passing along what the team learned during the investigation.

Why it matters

For anyone who administers shared development servers, Ptacek's assessment is blunt: he would be uneasy about people using VSCode remote editing on such hosts, and far angrier still if it were used against a production system in the middle of an incident. The concern is less about intent than capability — an unfamiliar component with arbitrary file writes, process spawning and persistence is precisely what you do not want arriving unannounced during an outage.

The post is also a useful corrective to the mental model many developers carry. "Remote editing" sounds like a thin shell over SSH; in VSCode's case it is a deployed service with broad reach. That knowledge should shape how teams scope credentials, network exposure and host policies for any machine an editor connects to — especially as agentic coding tools increasingly ride on top of that same remote path.

It is worth noting that the piece is one researcher's characterization of the design rather than a vulnerability report, and no vendor response appears in the source material. Ptacek's own framing is that none of it ultimately blocked Fly.io's integration; the point of publishing was simply that the team had to learn it, and now readers do too.