VSCode's SSH remote editing runs its own code on the host

Point VSCode at a remote host over SSH and it runs code on that host. A Bash snippet stager downloads an agent onto the box, including a binary build of Node, and runs it there.

Emacs has done remote editing for decades through Tramp, a pile of Elisp that hooks into an interactive SSH session and runs ordinary Bourne shell commands on the far end. Tramp lives off the land, using whatever is already on the remote host. VSCode built something much heavier out of the same idea. Rather than driving the tools already present, it installs its own Node runtime and its own agent, then talks to those.

The agent runs over port-forwarded SSH and opens a WebSockets connection back to your running VSCode front end. The protocol on that connection can walk the filesystem, edit arbitrary files, spawn its own shell PTY processes, and persist itself. Fly’s writeup notes there is a name in security for tools built this way, declines to print it, and allows only that the name is “murid in nature.” Murid means rodent. The word being avoided is RAT.

The remote-editing agent is, structurally, a remote access tool: code you did not write, running on a box you care about, holding a channel back to your laptop that can read and write files and launch processes. None of that reflects on VSCode’s intentions. You should still know the channel exists, and what it can do, before you open it against something that matters.

The Fly post’s own framing is the useful one. Its author would be “a little nervous” about letting people remote-edit on dev servers, and “apoplectic” if it happened against production during an incident. The reasoning holds. During an incident you are already unsure what is running where; adding a process that downloads a Node binary, spawns PTYs, and writes files onto the affected host puts more unknown code inside the blast radius at the worst possible time.

The context that prompted the investigation points at the fix. Everyone now runs forks of VSCode that generate code with an LLM, and the useful shape of that is an agent loop: the model writes code, the scaffolding runs it, the errors feed back to the model, and it iterates. You do not want that loop pointed at your laptop’s filesystem, because the model has no sense of boundaries and will iterate on your system configuration as cheerfully as on the git project you meant it to touch. The answer is a clean-slate Linux instance that spins up instantly and cannot screw you over, with the loop running there.

That is the right model for the remote-editing agent too. Treat the target as disposable. A throwaway VM you can burn is a fine place for VSCode to download Node and open its WebSockets channel. A long-lived dev server with credentials on it, or a production host in the middle of an incident, is not.