VS Code Remote-SSH Is Not a Sandbox: What the Fly.io "Bananas" Post Gets Right, and What Hacker News Argued About

Update — September 24, 2026: Related coverage — DeepSeek DSec agent sandboxes · OpenAI agent breached an Australian Medicare portal.

A blog post from February 2025 hit the Hacker News front page again on September 24, 2026, with 119 points and over 80 comments. The title: "VSCode's SSH Agent Is Bananas." The reason it resurfaced is timing. In 2026 far more developers run LLM coding agents on remote VMs and assume the VM is a safe sandbox. The post argues that a common way of reaching that VM, VS Code Remote-SSH, may quietly undo the sandbox.

This guide explains what the Fly.io post actually says, what Microsoft's own documentation confirms, what the Hacker News discussion got right and wrong, and how to build a remote agent setup that holds up. It connects to our work on sandboxing Claude Desktop and agent security incidents.

TL;DR

What the Fly.io post actually says

The author's motivation is spelled out early: developers want a clean-slate Linux instance that spins up instantly and cannot hurt you, where an LLM can iterate in a closed loop: "the LLM generates the code, the agent scaffolding runs the code, the code generates errors, the agent feeds it back to the LLM." That loop is the best-known antidote to hallucinated code, and it is also why you do not want it running on your laptop.

Then the twist: the post compares Emacs's Tramp, which "lives off the land" over an SSH shell, with VS Code's approach, which "mounts a full-scale invasion." VS Code runs a Bash snippet that downloads an agent, including a binary install of Node. The agent runs over port-forwarded SSH, and "establishes a WebSockets connection back to your running VSCode front-end." The protocol on that connection can wander the filesystem, edit arbitrary files, launch shell PTY processes, and persist itself.

The author hints that security folks have a name for tools that work this way (readers on Hacker News decoded it as a Remote Access Trojan) and adds that he would be "a little nervous" about people remote-editing on dev servers and "apoplectic" during an incident on production. He also notes the concern does not matter for Fly's specific integration, and that the post exists because "we've decided to just be a blog again."

Two claims that are easy to confuse

The discussion split because the post bundles two separate concerns.

Claim A: VS Code installs a lot of software on the remote host. True, and by design. VS Code Server (with Node) enables extensions, language servers and terminals on the remote. Commenters noted it can leave hundreds of megabytes on the host; one reported deleting 5.5 GB of stale server directories from a dev VM. That is annoying and expands the attack surface of a machine you meant to keep minimal, especially production hosts.

Claim B: the channel works in both directions. This is the sharper point. Microsoft's Remote-SSH extension page says: "Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine."

That sentence is the crux for AI agent users. If an LLM agent runs commands on the remote and something on that VM (a malicious dependency, a prompt-injected tool, the agent itself behaving badly) can talk to the editor's remote channel, the "sandbox" is no longer a sandbox for your laptop.

What Hacker News argued

The defenders. Many commenters use Remote-SSH daily for large teams and say the "disadvantages" are the advantages: consistent environments, extensions running remotely, port forwarding, dev containers. One said the tool is "a godsend" and that SSH access can be restricted to fit any guardrails. Another argued that a program designed to edit files and run commands on a remote machine can do exactly that, so "bananas" is unfair. Others explained the design: VS Code cannot assume the remote can reach the internet, so shipping the server over the SSH tunnel is the natural bootstrap.

The critics. Several replies pointed out that the objection is not about editing but about the reverse direction. One commenter put it as: a remote access protocol that lets an untrustworthy remote run code locally is a serious problem "in any scenario where the remote connection is presumed to be a one-way trust boundary," including when you deliberately run untrusted code on the remote yourself. Another said the concern is that Node and a VS Code server land on hosts that should be tightly controlled.

The decoders. A visible fraction of commenters assumed the post was about LLM agents and had to be corrected: the "agent" here is the SSH helper, not an AI. That confusion is understandable, since the post opens with LLM motivation.

The reality check. One commenter noted that "nothing has changed" since 2025 in terms of the trust issue, but that many more people now believe VM sandboxes plus Remote-SSH are safe. Another observed that the 2025 rant "seems quaint" next to how 2026 has gone, an allusion to the string of agent security incidents this year.

The alternatives. Commenters mentioned open-source Remote-SSH extensions for VSCodium, a system-SSH-based extension, editors with built-in remote support, Tramp with faster RPC backends, and serving VS Code in the browser from the VM with a private network. One person runs a terminal editor inside VS Code in the browser over a private network with no SSH. Trade-offs vary; several noted that some alternatives reinvent SSH clients poorly.

Why this matters for AI coding agents

If you run an LLM agent with shell access, you are running untrusted code by definition. The agent may follow hostile instructions from a web page, a README, or a dependency; see what indirect prompt injection is and the browser autonomy guardrails incident.

The safe design principle is simple: the sandbox boundary must hold in both directions.

Even a well-configured sandbox leaks through credentials. Practical rules:

1. Give the agent its own SSH keys and tokens, created per project, revocable, scoped to one repo or service.
2. Never forward your SSH agent into the VM. Forwarded agents let a compromised host use your keys.
3. Do not store your main cloud credentials on the VM.
4. Treat the VM as hostile: assume anything readable by the agent can be exfiltrated.
5. Pull results out as reviewed diffs, not by mounting your workstation into the VM.
6. Log everything. You should be able to reconstruct commands after an incident.

Anthropic's approach to restricting desktop access is a good reference; see Claude Desktop restrict access sandbox guide. For broader agent architecture, see what an agent harness is and harness engineering concepts.

If you must use VS Code Remote-SSH

It is a good tool for trusted machines. If you use it, harden the workflow.

• Only connect to hosts you own and trust. Microsoft's warning applies to any host where untrusted code runs.
• Keep untrusted agent work in a separate VM from the one you connect to with the editor.
• Use dev containers to isolate project dependencies, but remember the container is still on a host you connect to.
• Restrict the remote's network egress so a compromised host cannot easily phone home.
• Clean up server directories periodically; stale .vscode-server folders consume disk and add attack surface.
• Restrict SSH access with normal controls: key-based auth, allow lists, jump hosts and logging.
• Never use it on production incident boxes unless your organization has approved it; a guard rule keeps developers from installing extra runtimes on sensitive hosts.

One commenter's tip for administrators: an /etc/bashrc snippet that prints the message of the day when TERM_PROGRAM is vscode, since the extension bypasses the login banner.

Alternatives, by need

• You want a remote terminal and files: plain SSH with a terminal editor, or sshfs for file access (though it lacks remote extensions).
• You want the full VS Code experience on a remote box: serve the editor from the VM over a private network and open it in a browser, so no local editor process holds a channel into your machine.
• You use a VSCodium fork: community Remote-SSH extensions exist; evaluate their SSH handling and maintenance.
• You want team-standard environments: dev containers and cloud dev environments, with clear ownership of the host.
• You run agents: disposable VMs or containers, one per task, with nothing valuable in reach.

Bottom line

The Fly.io post is often read as an attack on VS Code. It is better read as a reminder about trust boundaries. Remote-SSH is designed for a trusted remote. When the remote runs untrusted, LLM-driven code, the direction of trust matters more than the convenience. If the VM is meant to be your sandbox, connect in a way that does not hand it a line back to your laptop, and keep secrets out of reach.

This article reflects the Fly.io post (published February 7, 2025), Microsoft's Remote-SSH documentation and the Hacker News discussion on September 24, 2026. Security properties depend on your configuration and versions; test your own setup.

Related reading

• Claude Desktop: restrict access and sandbox guide
• What is indirect prompt injection?
• AI agents and the Papercut breach: 395 organizations, 440 servers
• Agent browser autonomy guardrails viral incident
• What is an agent harness?
• Top 10 harness engineering concepts
• Cursor cloud agents in isolated VMs
• Official: Fly.io: VSCode's SSH Agent Is Bananas, Remote-SSH extension security note