VSCode’s SSH Agent feature is a remote editing tool that works by installing a Node binary on the machine you’re connecting to, then opening a WebSocket back to your editor so it can walk file systems, edit files and spawn shell processes. It is also, as one commentator put it, “bananas.”
The post’s author describes the feature as a “full-scale invasion,” a loaded term for a tool that runs a Bash snippet on the remote side to download and install a Node binary, then sets up a WebSocket connection back to the VSCode front-end. The author is concerned enough to warn readers not to let people VSCode-remote-edit on dev servers, and especially not during an incident on something in production.
What the SSH Agent Actually Does
The feature is designed to support a workflow where an LLM generates code, and the agent runs that code on the remote machine, captures errors, and feeds them back to the LLM for further iteration. The author frames this as a “semi-effective antidote to hallucination,” where the LLM writes the code and the agent executes it, catches failures, and sends those failures back to the LLM to try again.
That loop is useful in general, but the author argues it becomes extra useful when the loop happens on a clean-slate Linux instance rather than on your own development laptop. LLMs have “boundary issues,” the post says, and they will iterate on your system configuration just as happily as they will on the Git project you’re working in.
The problem, as the author sees it, is that the agent’s reach extends far beyond the code you’re trying to edit. It can walk the filesystem, edit arbitrary files, launch its own shell PTY processes, and persist itself — all over a WebSocket connection that stays open while the editor is running.
How It Compares to Tramp
The post draws a direct comparison to Emacs’s Tramp, which is described as “the spiritual forebearer of remote editing systems.” Tramp works by running Bourne shell commands on the remote connection, extending Emacs to that environment. The author suggests that Tramp is simpler, living off the land on the remote side, whereas VSCode’s approach involves downloading and installing a Node binary.
| Feature | Tramp (Emacs) | VSCode’s SSH Agent |
|---|---|---|
| Runs on the remote side | Yes, via Bourne shell commands | Yes, via Bash snippet |
| Downloads a binary | No | Yes, Node binary |
| Opens a WebSocket | No | Yes |
| Can edit arbitrary files | No | Yes |
| Can launch shell PTY processes | No | Yes |
| Can persist itself | Not addressed in the source | Yes |
The comparison is meant to illustrate the difference between a lightweight command runner and a full-scale agent that takes control of the remote machine.
Why the Author Is Concerned
The author’s stated concern is straightforward: you don’t want this iterative development process happening on your development laptop, because LLMs have boundary issues. On a clean-slate Linux instance that spins up instantly and can’t screw you over in any way, the loop makes sense. On a production server during an incident, it doesn’t.
The post stops short of naming the security category this falls into, saying only that the name is “murid in nature.” The author chooses not to say it out loud because that’s not fair to VSCode.
“It turns out we don’t have to care about any of this to get a custom connection to a Fly Machine working in VSCode, so none of this matters in any kind of deep way, but: we’ve decided to just be a blog again, so: we had to learn this, and now you do too.”
The author closes by noting that they don’t have to care about the feature to get a Fly Machine working. But the warning remains: the agent’s reach is wide, and the machine it reaches is yours.
What This Means for Users
For developers who use VSCode for remote editing, the practical takeaway is simple: know what you’re connecting to. The SSH Agent feature is powerful, but power carries risk. An LLM that can write code and an agent that can execute it and persist itself on a remote machine is a combination that could easily go wrong if the machine isn’t properly isolated.
The author’s advice is to avoid letting people VSCode-remote-edit on dev servers, and to be especially cautious during incidents on production systems. The feature is useful, but it demands careful management of the environment it runs in.
The post’s final line is a wry acknowledgment that the topic has been covered and the lesson learned. The author had to learn about the SSH Agent to set up a Fly Machine connection, and now they’re passing that knowledge along. For anyone else setting up remote editing, the lesson is clear: the agent is powerful, but it’s bananas.
Source material: “VSCode's SSH Agent Is Bananas (2025),” fly.io.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.