Fly.io details VSCode SSH agent architecture, security tradeoffs
Fly.io blog post examines VSCode's remote SSH editing system and its security implications for LLM-based agentic development.
What to know
- VSCode's SSH remote editing agent downloads a Node.js binary over SSH and establishes a WebSockets tunnel that grants broad local execution capabilities to the remote machine—differing significantly from Emacs Tramp's lighter-weight approach.
- Security concern: the protocol allows a compromised remote machine to initiate local code execution, edit files, and persist itself on the local VSCode host, raising risks for production use.
- Developer consensus splits: some view the architecture as fit-for-purpose and appropriate for dev environments with proper isolation; others worry about attack surface and reverse code execution from compromised remotes.
The dispute Whether VSCode's allowance of remote-initiated local execution is a design flaw or an acceptable tradeoff hinges on how tightly users isolate dev machines from production and whether they view the remote as a trusted component of the local system. · positions read across 23 posts and comments
VSCode's architecture is reasonable for remote dev; complaints misunderstand its intended threat model.
-
“So a program that is specifically designed to edit files and run arbitrary commands on a remote machine... can do so. Not sure where the bananas part comes in.”
10000truths · Hacker News ↗
Remote-initiated local code execution is a genuine security risk that should concern users.
-
“The issue the article highlights is this opens you to local code execution initiated by the remote.”
Rapzid · Hacker News ↗
VSCode's SSH implementation has practical operational issues beyond security.
-
“As a Linux user I've hated VSCode's ssh. There's lot of annoying things that make it harder to admin for. Like it doesn't pick up the MotD…”
godelski · Hacker News ↗
Fly.io Cloud platform operator
How it unfolded 2 developments, newest first · click a bar or a number to jump articlespostscomments
-
2
Developers debate threat model and real-world applicability
Hacker News commenters divided on severity: some argued VSCode's capabilities are intentional and appropriate for remote dev environments if properly isolated; others raised concerns about reverse code execution from compromised remotes and memory overhead.
“The issue the article highlights is this opens you to local code execution initiated by the remote.”
— Rapzid, HN commenter · source -
> The agent runs over port-forwarded SSH. It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can: Wander around the filesystem Edit arbitrary files Launch its own shell PTY processes Persist itself Wait, could someone clarify which machine is being referred to here?So in the…
2 more of the top 3 · 19 posts in this stretch
-
Allow me to translate this for the vibe bros. The "agent" here is not an LLM agent, it's the SSH agent that connects the VSCode front-end to the remote back-end.The issue the article highlights is this opens you to local code execution initiated by the remote.Here is the security notice on the official SSH extension…
-
I have been using VSCodium (chromium-like version of VSCode) with this extension:https://github.com/jeanp413/open-remote-sshI run the editor (and its extensions), my projects and any agent harnesses from inside a container and use that extension to get an editor.This is mostly to protect my credentials and data from malicious…
-
-
1
Post highlights bidirectional execution risk in VSCode remote protocol
The Fly.io analysis identifies that VSCode's WebSockets-based remote protocol allows the agent on the remote machine to wander the filesystem, edit arbitrary files, launch shell processes, and persist itself—granting broad execution capabilities initiated by the remote.
“In security-world, there's a name for tools that work this way. I won't say it out loud, because that's not fair to VSCode, but let's just say the name is murid in nature.”
— Fly.io -
1 outlet VSCode's SSH Agent Is Bananas
first by HN Frontpage, 16h ago
-
When I give an agent ssh access to something I want to be able to watch and fully understand what it's doing. I want it to essentially only "type" things into the CLI that I could have typed myself, I can comprehend what it's doing, and am not surprised by the results. Opencode and a smart LLM (qwen 3.8-flash-next, deepseek v4 0731 or smarter) do…
2 more of the top 3 · 4 posts in this stretch
-
H
VSCode's SSH Agent Is Bananas L: https:// fly.io/blog/vscode-ssh-wtf/ C: https:// news.ycombinator.com/item?id=4 9822555 posted on 2026.09.23 at 17:01:48 (c=0, p=4)
-
Missing a (2025)FYI VSCode's SSH Agent is a godsend for remote development - the "disadvantages" that Fly lists are part of its advantages. I've worked in several teams that have made extensive use of the extension, and it's never been an issue. You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.
-
-
background
Fly.io publishes analysis of VSCode SSH agent architecture — Fly.io published a blog post examining how VSCode's remote SSH editing feature works, comparing it to Emacs Tramp and detailing the security model of VSCode's approach, which involves downloading a Node.js-based agent that runs over port-forwarded SSH.
What people are saying 17 voices from 1 site · best of 23 · verbatim
- Today
-
> You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.How, specifically for VSCode?
-
2026-09-24 09:35:24 dev ~ du -h -d 0 .vscode-server 6.0G .vscode-server This is what makes it bananas for me. I don't know what Microsoft is thinking if they allow this. 2026-09-24 09:35:29 dev ~ python3 python/stuff/cleanup-vscode.py === cli/servers === KEEP Stable-a5b500951314efd502d07465bd138dfbd714a960 678.2 MB === bin === KEEP…
-
It's unusable on low end 512MB RAM VPS servers because someone decided bundling whole node runtime for file operations is a good idea.
-
I'm also on the verge to decide if to ban those vscode reverse shells in my servers. devs will cry for sure. Local claude cli instances are OK, I think, but remote is a huge risk.
-
The author didn't go into much explanation behind "I would be a little nervous about letting people VSCode-remote-edit stuff on dev servers".If you are worried about having VSCode server-side binaries running directly on the bare metal OS you can isolate the workspace using containers or VMs.
-
> ”hallucination” is what we call it when LLMs get code wrong; “engineering” is what we call it when people do.They've lost me right there at the top of the article. This sounds like a pure hatred and ignorance to what the actual software engineering is.
- Yesterday
-
i got tired of vscode always complaining about sth. I am liking neovim and Jetbrains IDEs, these never gave me any headache.
-
I like VSCode server in general, but it's too memory hungry. It would crash Raspberry Pi (1GB) by eating up all the RAM.
-
I wonder if the same reverse code execution risk applies to the VSCodium extensions
-
I’ve been using it daily since it came out. At first it was because I was tired of docker slowing my Mac down with some really heavy client projects. But now I use it as an easier ssh client w/ file editing. I really don’t like using vim/nano. Keeping everything in the same ide, huge for me.
-
Why not sshfs? Been using that for ages, since before VSCode existed. Is it suddenly broken?
-
As a Linux user I've hated VSCode's ssh. There's lot of annoying things that make it harder to admin for. Like it doesn't pick up the MotD, preventing me from showing users important messages. I've found that it also doesn't reuse sessions (at least by default. TBF, neither does ssh) and I'll find that there's just dozens of open sessions over…
-
Nothing has changed as far as the insecurity the article has outlined.The problem is the remote host has control over local host through the protocol.
-
So a program that is specifically designed to edit files and run arbitrary commands on a remote machine... can do so. Not sure where the bananas part comes in. Sending a binary over SSH/SFTP might sound weird at first glance, but VSCode can't assume that your remote machine can access the wider internet, and it needs a reliable way to bootstrap…
-
Yeah this is the right architecture for remote editing with remote tools. It works really well. (There are longstanding bugs around reconnection when the SSH connection is broken but that's not the fault of the architecture.)
-
The agent is supposed to run on a remote dev box. The purpose is to make the remote machine an extension of your local one, to run extensions, containers, install packages, test deployments, forward ports and tons more. Tunneling is part of the feature set. If you are installing it on production servers and are surprised by its behavior that’s on…
-
This part of VSCode's architecture is acceptable to me. The reverse direction, where a compromised remote can do whatever it wants to my local machine, is not.