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.

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 the agent on the remote. Shipping it over the SSH tunnel is the natural solution.

  2026-09-24 09:35:24 dev ~ du -h -d 0 .vscode-server
  6.0G    .vscode-server                                                                                                                               

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 you.

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.

> 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 author's setup, he runs VSCode (i.e. the front-end) on his dev laptop, which he wants to keep free of direct LLM access.

VSCode connects via ssh to a dedicated "sandbox" machine on which the LLM will be free to do whatever it wants (mostly).

VSCode realizes this the Microsoft way, by using the ssh connection to install VSCode Server on the sandbox machine - the "backend" - and communicating through it via a websocket connection.

So then, what happens? If the websocket connection allows the front-end to run arbitrary commands on the sandbox machine, this wouldn't be very exciting: The front-end already has an ssh connection and a massive server process that can do the same - and the entire purpose of the sandbox machine is to run arbitrary, untrusted commands without harm.

But the article says the websocket connection goes "back to your running VSCode front-end". So does that mean things are reversed? I.e. the agent/harness runs in the server on the sandox machine but for some reason has this websocket connection that also lets it run arbitrary commands on the dev laptop?

Is that it? That would be truly insane!

> ”hallucination” is what we call it when LLMs get code wrong; “engineering” is what we call it when people do.

When people get it wrong, we call that a mistake. LLMs don't get the privilege of making mistakes, because there's no evidence of the idea required for something to even be a mistake. Can't call something unintended when there was no intention to begin with. (You absolutely can call it a mistake or unintended on the part of an operator -- I wouldn't say so of the LLM itself though.)

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 relatively well with this in my experience.

I think the last time I linked SSH to a few V'sM through VSCode it auto-installed node, npm, and hundreds of megabytes of npm packages, then it persisted a node service. It's bananas that it still does this. I have never used SSH through VSCode again.

I avoided Zed for a long time because of the SSH feature in VScode. Then I realized Zed has SSH remote too. Just flagging this for anyone else who relies on vscode-over-ssh and is sick of the bloat.

I’m currently experimenting with running:

- neovim

- in VS Code [1]

- in the browser

Cloud VM runs the built-in `code serve-web` command, over Tailscale using `tailscale serve`. No SSH. Extensions work. No extensions run locally (with SSH some extensions have to run locally on your machine).

I’m trying to see how little I can run on my local machine. VS Code over SSH is a good step in that direction, but there’s more attack surface if SSH is misconfigured, plus risk of an extension getting compromised.

I expected the added layers (neovim, through an extension, inside VS Code, over the web) to be slow, but so far it works surprisingly well.

[1] https://github.com/vscode-neovim/vscode-neovim

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 https://marketplace.visualstudio.com/items?itemName=ms-vscod...

> Using Remote-SSH opens a connection between your local machine and the remote. 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.

Yes this article is from Feb 2025, but NOTHING HAS CHANGED in this regard. Except perhaps now MANY MORE PEOPLE are believing they are safe using VM and other remote SSH "sandboxes" to develop on via VSCode remote host connection over SSH. The reality is, as stated by Microsoft themselves, if you can't trust the remote.. It can own your local computer. And that's not much of a "sandbox"..

I did build "RAT"-like (Remote Administration Tool) infra with automated http api generation for various tasks, my coworkers and I enjoyed using it.

But even when starting that, I was aware such patterns and remote access, yeah, this just has C&C botnet capabilities too.

It's not that deep, but there certainly is overlap with malware-esque patterns.

Discussed at the time:

VSCode’s SSH agent is bananas - https://news.ycombinator.com/item?id=42979467 - Feb 2025 (511 comments)

(Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers)

feel the same as since I am doing more reading code and reviewing md files more than real modify code with agents now. VS Code, even with the remote mode is a big waste of my dev box (the resouce used by VS Code cli is no small). And after seeing herdr and omarchy, I realized what I really need is not a better remote code editor now (even Zed is too heavy), but an enhanced multi term through web page, so I developed my own tool called suwu, https://suwu.liyu1981.xyz, it is a tiling term session manager can drive herdr perfectly, but also (along with my own need), add many small tools like git graph, file browser, file reader, and even a X display in web.

> ”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.

Why not sshfs? Been using that for ages, since before VSCode existed. Is it suddenly broken?

I wonder if the same reverse code execution risk applies to the VSCodium extensions

This extension and devcontainers is basically the way to go for large dev teams inmho

For my own agent one of the design constraints is that it can't get out of the work directory, and it can't even try to guess the full path of that directory. Interesting that VSC has gone the other way entirely.

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.

This 2025-era rant seems quaint in comparison to how 2026 has gone.

I always assumed VSCode Remote SSH was basically just SSH with some extra tooling. Turns out it’s a whole different beast.

Was author trying to avoid the word "rootkit"?

I like VSCode server in general, but it's too memory hungry. It would crash Raspberry Pi (1GB) by eating up all the RAM.

Moreover, it explicitly breaks in VSCodium and no good alternatives exist.

> It turns out we don’t have to care about any of this [...], 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.

I found this closing sentence utterly delightful, particularly in an age of endlessly filtering every piece of text I read on the internet through a mental "was this written by Claude, Codex, or (just possibly) a human?" filter.

i got tired of vscode always complaining about sth. I am liking neovim and Jetbrains IDEs, these never gave me any headache.

I should call my dev machine the Fly Machine too

I am honestly surprised there wasn't a big VS Code Extension targeted npm attack.

440hz

Honestly now that I'm basically dictating ai on what to do I've really stopped using all guis. Terminal is all I need.

[flagged]

[flagged]

Jfkkfhbsbu gg Hacker para free fire Qué tal y me enseñas cómo poner este hac V gg d tu gffc

..nkejejekfjehkelttkrk

Urhbguhudgjjcćdk Rjrjfjejehebf Free fire quiero crear un hacker para ser el mejor de la historia un hacker para poder ser el mejor de la historia y poder derrotar aika un hacker suficiente fuerte para que garena no me bañ

off topic, but I feel this observation was quite early in feb' 2025: "LLM-generated code is useful in the general case if you know what you’re doing. But it’s ultra-useful if you can close the loop between the LLM and the execution environment (with an “Agent” setup)."

kudos

Misguided post, as you can see when you consider what VSCode and SSH are for.

> Emacs hosts the spiritual forebearer of remote editing systems, a blob of hyper-useful Elisp called “Tramp”. If you can hook Tramp up to any kind of interactive environment — usually, an SSH session — where it can run Bourne shell commands, it can extend Emacs to that environment.

vs.

> 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.

So... basically the same things that Tramp could do as well?

> 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.

Yeah, it's called RAT, and an ur-example of it is SSH itself (especially when allowed to run a shell remotely), so... not sure why are you freaking out.

I mean, I'd probably prefer if VS Code simply ran ed/vim remotely, but both of those editors can invoke shell anyhow so... eh?

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.

The problem isn't that it can edit remote files or run remote shell commands.

The problem is that it appears to do this via an AI Agent. This broadens the security concerns significantly.