VSCode's SSH Agent Is Bananas (2025)

Originally published by The Fly Blog

The marketing gods demand conversion metrics, so here is the standard disclaimer: Fly.io uses analytics cookies to track traffic and ad conversions on our documentation and marketing pages. These are strictly for logged-out users; we don't track your activity within the dashboard.

Author: Thomas Ptacek (@tqbf)
Reading Time: $\approx 3$ minutes

---

The Drive Toward "Agentic" Workflows

Fly.io is interested in integrating with the remote editing pipeline used by VSCode. The reasoning is simple: VSCode has become the industry standard, especially with the rise of forks that integrate Large Language Models (LLMs) for code generation.

There is a distinct difference in terminology here:

"Hallucination" is the term for when an LLM gets the code wrong; "engineering" is what we call it when humans do.

While LLM-generated code is generally helpful if the user is skilled, it becomes exceptionally powerful when you close the loop between the model and the environment. This is the "Agent" setup.

The Feedback Loop

The process can be represented mathematically as an iterative cycle: $\text{LLM} \rightarrow \text{Code Generation} \rightarrow \text{Execution} \rightarrow \text{Error Feedback} \rightarrow \text{LLM}$

The danger here is the execution environment. You do not want this iterative process running on your local machine. LLMs lack boundaries; they are just as likely to "iterate" on your critical system configurations as they are on the Git repository you are actually working on.

The ideal solution is a "clean-slate" Linux instance—one that boots instantly and is completely isolated so the LLM cannot destroy your life screw over your host system.

---

A Tale of Two Remote Systems: Tramp vs. VSCode

To understand why VSCode's approach is "bananas," we have to look at the spiritual ancestor of remote editing: Tramp (a powerful collection of Elisp in Emacs).

The Comparison

While Tramp simply leverages the existing remote shell, VSCode employs a more aggressive strategy. It runs a Bash snippet that downloads a full agent, including a binary installation of Node.

What the VSCode Agent Can Do

Once the WebSocket connection is established, the agent has extensive permissions:

• Navigate the entire filesystem
• Modify any arbitrary file
• Spawn its own shell PTY processes
• Maintain persistence on the host

In the cybersecurity world, tools that operate with this level of autonomy and stealth have a specific name. I won't say it explicitly to be fair to the VSCode team, but the name is murid in nature (i.e., a Remote Access Trojan).

# Conceptual representation of the VSCode stager
curl -sSL https://vscode-remote-agent-download.com/install.sh | bash
# Now Node.js is running on your server...

---

Final Thoughts

If I saw someone using VSCode remote editing on a development server, I'd be nervous. If it happened during a production incident, I would be apoplectic.

Ultimately, we managed to get a custom connection to a Fly Machine working within VSCode, so these architectural concerns didn't stop us from achieving our goal. However, since we've decided to return to our roots and be a company just be a blog again, we figured we should share the knowledge we gained.

Next Up: $\uparrow$ A Blog, If You Can Keep It
Previous: $\downarrow$ AI GPU Clusters, From Your Laptop, With Livebook