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.
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 months from users. I literally had to write a script to boot people...
It would be one thing if the plugin was just a wrapper and people were still expected to know ssh but the plugin abstracts away all that and is intended to make it a "use VSCode on remote machine" tool. So it needs to do more than just handle creds, otherwise it creates a divergent experience while making people think it's just ssh
> There's lot of annoying things that make it harder to admin for.
It also (AIUI) tries to walk the entire file tree, so have fun with NFS (auto)mounts.
It also amounts to letting off fork bombs: we set up limits for a maximum of 256 process per UID, and regularly get folks asking "what does this 'cannot fork' message mean?": it mean you're trying to DoS the system.
The one this that is better than just SSH+Tmux+Vim, is that if your latency is higher than 30-50ms, since VSCode's SSH agent streams the files to your computer, the typing experience feels snappier. When you work half a continent away from where the servers are, it makes life nicer.
> I'll find that there's just dozens of open sessions over months from users
We've had the same issue with our local HPC; a few login nodes serving hundreds of users at a time, and each login node used to get swamped by these dangling SSH sessions/servers. They also wrote a script that shuts down all sessions once a day to save the login nodes.
I 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 extensions/dependencies/rogue-agents, bu it also lets me quickly port my dev environment to any machine (I use linux at home and macos at work). Just install podman, install VSCodium, add the SSH extension, build image, add my utility shellscripts (to quickly get in and out of the container in a shell) and done.
Apparently Microsoft keep some VSCode APIs proprietary so only its own extensions can use it (allegedly for security reasons), which is why this specific extension only works in VSCodium. I wonder if it is vulnerable to the same things the article points out.
I used VSCodium before and found it to be a massive waste of time for no benefit. A significant number of extensions either aren't in OpenVSIX (or whatever it's called), or don't work for some reason.
Just disable telemetry in VSCode and you're good.
Also using it, and by now at least I see the reason why they did it. VSCode has a large plugin ecosystem, many which are essential for development. The problem is that those plugins don't know anything about remote development and expect to use the standard file system and OS APIs to interact with the workspace.
So how to make the plugins remote-capable? You could write a massive virtualization layer that captures all system calls and forwards them to the remote - or, you could run the plugin on the remote and just pass the user commands and UI updates over the connection.
VSCode does the latter, so the nodejs runtime is where all the plugins are running on the remote.
(I understood the reason, I didn't say it was a good reason...)
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.)
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.
it's worse than that, last i looked into this - there's functionality in the protocol that allows the remote system to modify files and execute code on the local/frontend system. it really is bananas.
Edit: there's a security note (still) on the remote ssh extension page:
Security Note
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.
The ethos of VSCode was supposed to be lightweight, something like Notepad++ with a terminal. Developers have lost the plot. Please recommend Visual Studio if you would like a feature-rich SSH agent. I think developer trends have supercharged VSCode and it feels shinier and new with all the extensions but this is an anti-pattern; it defeats the whole purpose.
I don’t think it was ever intended to be lightweight like Notepad++ given the architectural designs from the outset (LSP, Chromium-base, etc).
It always felt to me more like a desperate attempt by Microsoft to regain the IDE market share as low end FOSS editors started taking over. So MS wanted to appeal to the open source community.
And it worked. Even if the primary build of VSCode which most people run isn’t technically open source.
For all practical purposes VSCode is a vessel to sell AI, im using vscodium for now but expect a cycle reset for it this decade (someone makes a new lightweight IDE etc)
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.
TRAMP (mentioned in the article) does it without installing anything on remote machine, just SSH, and shell commands. Which sounds more natural to me. Node.js security history, with all due respect, is not shiny. And the problem the author has with VSCode's way, I guess, is not that it can edit files, but that it extends attack surface without real need.
TRAMP actions are also rather slow (high latency). OTOH, tramp-rpc relies on a little tool to run on the remote and is much snappier. This proves there is a better middle ground than TRAMP with nothing and whatever abomination VSCode injects. Basically, busybox with a persistent RPC connection is all one needs.
I think the actual concern, not well expressed in the blog post, is the fact that node and vscode server are installed on, for instance, a prod machine that (probably) should be very tightly controlled in terms of what software is installed and running. You don't want to unwittingly add to the attack surface
This should be covered by not giving developers SSH shell or equivalent access to production machines in the first place, or at the very least to have measures in place (ACLs, quotas, etc.) to strictly limit what they are able to do from the shell.
Yeah, I learned how it worked when I made the mistake of trying to use it to develop on a Raspberry Pi, where it filled the disk and crashed/hung the Pi by using all the RAM until it started using swap. Fell back to local with an sshfs mount instead.
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.
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.
> # Security Note
>
> 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.
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.
Security Note
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.
> 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?
Yes, the "agent" is not an LLM agent here it's the "ssh agent" that connects VSCode front-end to the remote server back-end..
It's astonishing how many commentors(not you!) either didn't read or didn't understand the blog post, saw "agent" and thought LLM agent, and then decided to comment about it...
> Wait, could someone clarify which machine is being referred to here?
I'm not the author, but I can tell that he means the remote machine. His sentence about being "nervous about letting people VSCode-remote-edit stuff on dev servers, and apoplectic if that happened during an incident on something in production" makes it clear. He considers the VS Code agent to have all the features of a rootkit, and doesn't want anyone to be deploying it onto dev servers, let alone production ones.
That makes no sense to me though. The VSCode frontend already has an open SSH connection to the remote machine, over which it could do the same things and more. Why is the websocket connection (which is probably tunneled through the SSH connection anyway?) any worse here?
Edit: another comment clarified it really goes both ways: The remote can use it to run code on the local machine as well, exactly what the "sandbox" pattern was supposed to prevent.
This article is about a vulnerability most people aren't aware of in the VSCode remote connection protocol that those same people believe is helping them "sandbox" their LLM agent development....
Look, I have no idea what the tool I’m using does, how it works, or what problems it solves. All I know is it doesn’t work as I want it to.
Back in 2008 I was working in a team that was trying to reduce build breaks in a company. It was rudimentary implementation of current CI systems meant to avoid breaking the nightly builds. It just ran a `make build` on a clean machine and let you see the output when it was done. One guy opened a “sever security vulnerability” because in his patch he replaced build target with the equivalent of a `curl | bash` and proclaimed that he hacked the build system. “You should verify what the patch is doing before running it” he said.
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.
And if everyone was like you AI safety wouldn't be that large of concern. The default human behavior seems to be fire and forget which can go off the rails really quick.
It's not like I've never told an agent to build an ssh tunnel or some sort of more persistent connection between my dev machine running the harness and the remote thing it is talking to as an SSH client... Just that I don't want it going and doing that proactively unless I specifically define the parameters first.
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.
> 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'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.
There is a huge difference between running sshfs and vscode remote.
vscode remote tries to completely put the user on the remote machine, the terminal, the environment and anything else the remote box has access to the user can work with it. It allows me to connect to my dev environment (remote box) from any PC, or with the right setup even a browser.
In my team this allowed us to setup a consistent dev environment where everyone has access to the same specs, same environment, easy to manage access control sensitive systems from that remote machine on forward etc... sshfs or using sftp that many of the older IDEs did, don't come close to making it so seamless.
I must have been doing something different then. Ages ago we had devs using remote vns, shell in and also remote mount and then run and debug, they could work from office or home or road; consistent devenv. Granted we had to have cfEngine (then Puppet IIRC) help us. In 2026 we've got containers for almost everything but, I still work with some legacy-ass systems doing things this way. We've added more ceremony and more code but, the workflow is not significantly improved, IMO. I don't get new features, just nee ways of doing the same old.
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.
You would think, now that we're running demon-powered code on our sandboxed machine, that allowing that machine to have full control over the local client would be considered a bad idea.
But Microsoft won't fix VSCode because it would possibly impede usability by amateurs, and inject tedious security concepts like boundaries into the dev process.
That's the word I thought he was hinting at... but then I looked up the word "murid". It has two meanings, one from Sufism (a novice seeking spiritual enlightenment) and one from science (muridae is the family of rodents that includes rats and mice). Neither one of those seems to match "rootkit". I suspect he intended the mice-and-rats meaning, but I don't know what word related to rats or mice might have a similar meaning to "rootkit".
EDIT: Found it. He's referring to the acronym RAT meaning "Remote Access Trojan" (or, if actually intended, Remote Administration Tool).
Since muridae is the family of rodents that includes rats and mice, I believe he's referring to a RAT, a Remote Access Trojan. Something that functions rather like https://hunt.io/malware-families/reversessh or other similar malware, in other words.
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.
> ”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.)
Not sure what you consider "no good" alternatives. jeanp413.open-remote-ssh[0] has worked flawlessly. It's the first or second search hit in the extension manager for "ssh". It's a fork of Microsoft's previous extension before the proprietarized it.
I very much dislike this extension because it uses a built-in ssh client that is far from feature complete and does a lot of reinventing the wheel. Microsoft's extension uses the system ssh binary, as does https://open-vsx.org/extension/aergic/zygos-vscodium which I much prefer. After discovering the latter, I uninstalled VSCode and have fully moved to VSCodium.
> 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.
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.
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.
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)."
> 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 difference is that there is an SSH agent at all, whereas Emacs just uses the built-in Bourne shell.
Some people get an icky feeling where remote editing tools change the remote filesystem in any way that is not explicitly done by the user. A binary installation of Node is extra extra icky. (I don’t have Node installed anywhere on my computers; I avoid JS if possible and if not I prefer Deno.)
No, with TRAMP its a one way thing. The remote side can't wander around the local side at all, at least from my understanding of TRAMP. So it's no the same at all.
Wait, you mean that with the VS Code protocol, the remote side can send the commands to my local VS Code, making it do all kinds of funny stuff? Seriously? That's not really obvious from TFA at all and mostly reads as their unease with running somewhat opaque piece of software at the remote written for Node instead of presumably well-maintained bunch of sh scripts (a very interesting supposition IMHO).
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.
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.
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 months from users. I literally had to write a script to boot people...
It would be one thing if the plugin was just a wrapper and people were still expected to know ssh but the plugin abstracts away all that and is intended to make it a "use VSCode on remote machine" tool. So it needs to do more than just handle creds, otherwise it creates a divergent experience while making people think it's just ssh
> There's lot of annoying things that make it harder to admin for.
It also (AIUI) tries to walk the entire file tree, so have fun with NFS (auto)mounts.
It also amounts to letting off fork bombs: we set up limits for a maximum of 256 process per UID, and regularly get folks asking "what does this 'cannot fork' message mean?": it mean you're trying to DoS the system.
5 replies →
I don't think I've ever paid attention to a MotD on any of the servers I had a ssh access to... what do people put there?
9 replies →
And it’s really opaque. Would be fine if it were an open source package but there’s a lot of mystery behind how it’s implemented.
13 replies →
The one this that is better than just SSH+Tmux+Vim, is that if your latency is higher than 30-50ms, since VSCode's SSH agent streams the files to your computer, the typing experience feels snappier. When you work half a continent away from where the servers are, it makes life nicer.
> I'll find that there's just dozens of open sessions over months from users
We've had the same issue with our local HPC; a few login nodes serving hundreds of users at a time, and each login node used to get swamped by these dangling SSH sessions/servers. They also wrote a script that shuts down all sessions once a day to save the login nodes.
Well, it's better than JetBrains Remote Development which opens a new SSH connection every second.
I have been using VSCodium (chromium-like version of VSCode) with this extension:
https://github.com/jeanp413/open-remote-ssh
I 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 extensions/dependencies/rogue-agents, bu it also lets me quickly port my dev environment to any machine (I use linux at home and macos at work). Just install podman, install VSCodium, add the SSH extension, build image, add my utility shellscripts (to quickly get in and out of the container in a shell) and done.
Apparently Microsoft keep some VSCode APIs proprietary so only its own extensions can use it (allegedly for security reasons), which is why this specific extension only works in VSCodium. I wonder if it is vulnerable to the same things the article points out.
I used VSCodium before and found it to be a massive waste of time for no benefit. A significant number of extensions either aren't in OpenVSIX (or whatever it's called), or don't work for some reason. Just disable telemetry in VSCode and you're good.
Happy Ungoogled Chromium user though
3 replies →
Also: https://news.ycombinator.com/item?id=49824802
It's unusable on low end 512MB RAM VPS servers because someone decided bundling whole node runtime for file operations is a good idea.
Also using it, and by now at least I see the reason why they did it. VSCode has a large plugin ecosystem, many which are essential for development. The problem is that those plugins don't know anything about remote development and expect to use the standard file system and OS APIs to interact with the workspace.
So how to make the plugins remote-capable? You could write a massive virtualization layer that captures all system calls and forwards them to the remote - or, you could run the plugin on the remote and just pass the user commands and UI updates over the connection.
VSCode does the latter, so the nodejs runtime is where all the plugins are running on the remote.
(I understood the reason, I didn't say it was a good reason...)
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.)
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.
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.
> You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.
How, specifically for VSCode?
“A tool with a purpose of editing files on a remote system can edit files on a remote system.”
it's worse than that, last i looked into this - there's functionality in the protocol that allows the remote system to modify files and execute code on the local/frontend system. it really is bananas.
Edit: there's a security note (still) on the remote ssh extension page:
Security Note 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.
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
4 replies →
Shock and horror!
The ethos of VSCode was supposed to be lightweight, something like Notepad++ with a terminal. Developers have lost the plot. Please recommend Visual Studio if you would like a feature-rich SSH agent. I think developer trends have supercharged VSCode and it feels shinier and new with all the extensions but this is an anti-pattern; it defeats the whole purpose.
I don’t think it was ever intended to be lightweight like Notepad++ given the architectural designs from the outset (LSP, Chromium-base, etc).
It always felt to me more like a desperate attempt by Microsoft to regain the IDE market share as low end FOSS editors started taking over. So MS wanted to appeal to the open source community.
And it worked. Even if the primary build of VSCode which most people run isn’t technically open source.
5 replies →
For all practical purposes VSCode is a vessel to sell AI, im using vscodium for now but expect a cycle reset for it this decade (someone makes a new lightweight IDE etc)
This is what makes it bananas for me. I don't know what Microsoft is thinking if they allow this.
> I don't know what Microsoft is thinking if they allow this.
First time?
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.
TRAMP (mentioned in the article) does it without installing anything on remote machine, just SSH, and shell commands. Which sounds more natural to me. Node.js security history, with all due respect, is not shiny. And the problem the author has with VSCode's way, I guess, is not that it can edit files, but that it extends attack surface without real need.
TRAMP actions are also rather slow (high latency). OTOH, tramp-rpc relies on a little tool to run on the remote and is much snappier. This proves there is a better middle ground than TRAMP with nothing and whatever abomination VSCode injects. Basically, busybox with a persistent RPC connection is all one needs.
1 reply →
I think the actual concern, not well expressed in the blog post, is the fact that node and vscode server are installed on, for instance, a prod machine that (probably) should be very tightly controlled in terms of what software is installed and running. You don't want to unwittingly add to the attack surface
This should be covered by not giving developers SSH shell or equivalent access to production machines in the first place, or at the very least to have measures in place (ACLs, quotas, etc.) to strictly limit what they are able to do from the shell.
Fair enough, but running VSCode on a prod machine is also bananas.
7 replies →
Pre-Download a known good VSCode server binary. VSCode will detect and use it.
What more could you ask for?
Am I that much of? My reading of the following was that the remotely executed agent pushes commands back to your local vscode.
> [...] VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node. [...]
> It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:
The bananas part is that it dumps 500 MB of stuff on the remote side.
Yeah, I learned how it worked when I made the mistake of trying to use it to develop on a Raspberry Pi, where it filled the disk and crashed/hung the Pi by using all the RAM until it started using swap. Fell back to local with an sshfs mount instead.
I just removed 5.5Gb of stale ~/.vscode-server from a dev VM
1 reply →
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.
— https://marketplace.visualstudio.com/items?itemName=ms-vscod...
The issue is that the model can be the attacker, and use the link back to your host.
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.
It also makes your local client an extension of the remote box. That is going directly against expectations for remote access.
It's right there though:
> # Security Note > > 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.
From https://marketplace.visualstudio.com/items?itemName=ms-vscod...
Big bold text and everything
1 reply →
I think it is so that the server extensions can do stuff on the client, imo the weirder part is that it installs a bunch of stuff on the remote
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.
it does the reverse direction also. there's a security note indicating such on the remote ssh vscode extension page https://marketplace.visualstudio.com/items?itemName=ms-vscod...
Security Note 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.
The part you find unacceptable is the entire point of the article..
> 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:
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!
Yes, the "agent" is not an LLM agent here it's the "ssh agent" that connects VSCode front-end to the remote server back-end..
It's astonishing how many commentors(not you!) either didn't read or didn't understand the blog post, saw "agent" and thought LLM agent, and then decided to comment about it...
Before reading I thought of the classic meaning of an SSH Agent, which saves your private keys
> Wait, could someone clarify which machine is being referred to here?
I'm not the author, but I can tell that he means the remote machine. His sentence about being "nervous about letting people VSCode-remote-edit stuff on dev servers, and apoplectic if that happened during an incident on something in production" makes it clear. He considers the VS Code agent to have all the features of a rootkit, and doesn't want anyone to be deploying it onto dev servers, let alone production ones.
That makes no sense to me though. The VSCode frontend already has an open SSH connection to the remote machine, over which it could do the same things and more. Why is the websocket connection (which is probably tunneled through the SSH connection anyway?) any worse here?
Edit: another comment clarified it really goes both ways: The remote can use it to run code on the local machine as well, exactly what the "sandbox" pattern was supposed to prevent.
1 reply →
> ”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.
This article is about a vulnerability most people aren't aware of in the VSCode remote connection protocol that those same people believe is helping them "sandbox" their LLM agent development....
....
....
Look, I have no idea what the tool I’m using does, how it works, or what problems it solves. All I know is it doesn’t work as I want it to.
Back in 2008 I was working in a team that was trying to reduce build breaks in a company. It was rudimentary implementation of current CI systems meant to avoid breaking the nightly builds. It just ran a `make build` on a clean machine and let you see the output when it was done. One guy opened a “sever security vulnerability” because in his patch he replaced build target with the equivalent of a `curl | bash` and proclaimed that he hacked the build system. “You should verify what the patch is doing before running it” he said.
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.
And if everyone was like you AI safety wouldn't be that large of concern. The default human behavior seems to be fire and forget which can go off the rails really quick.
It's not like I've never told an agent to build an ssh tunnel or some sort of more persistent connection between my dev machine running the harness and the remote thing it is talking to as an SSH client... Just that I don't want it going and doing that proactively unless I specifically define the parameters first.
5 replies →
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"..
Microsoft has still refused to setup any kind of extension sandboxing, so it seems clear they consider a warning notice sufficient security.
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.
Why not sshfs? Been using that for ages, since before VSCode existed. Is it suddenly broken?
There is a huge difference between running sshfs and vscode remote. vscode remote tries to completely put the user on the remote machine, the terminal, the environment and anything else the remote box has access to the user can work with it. It allows me to connect to my dev environment (remote box) from any PC, or with the right setup even a browser.
In my team this allowed us to setup a consistent dev environment where everyone has access to the same specs, same environment, easy to manage access control sensitive systems from that remote machine on forward etc... sshfs or using sftp that many of the older IDEs did, don't come close to making it so seamless.
I must have been doing something different then. Ages ago we had devs using remote vns, shell in and also remote mount and then run and debug, they could work from office or home or road; consistent devenv. Granted we had to have cfEngine (then Puppet IIRC) help us. In 2026 we've got containers for almost everything but, I still work with some legacy-ass systems doing things this way. We've added more ceremony and more code but, the workflow is not significantly improved, IMO. I don't get new features, just nee ways of doing the same old.
1 reply →
Because vscode needs to run language servers on the target machine as well.
I wonder if the same reverse code execution risk applies to the VSCodium extensions
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.
This extension and devcontainers is basically the way to go for large dev teams inmho
I like VSCode server in general, but it's too memory hungry. It would crash Raspberry Pi (1GB) by eating up all the RAM.
This 2025-era rant seems quaint in comparison to how 2026 has gone.
You would think, now that we're running demon-powered code on our sandboxed machine, that allowing that machine to have full control over the local client would be considered a bad idea.
But Microsoft won't fix VSCode because it would possibly impede usability by amateurs, and inject tedious security concepts like boundaries into the dev process.
Was author trying to avoid the word "rootkit"?
That's the word I thought he was hinting at... but then I looked up the word "murid". It has two meanings, one from Sufism (a novice seeking spiritual enlightenment) and one from science (muridae is the family of rodents that includes rats and mice). Neither one of those seems to match "rootkit". I suspect he intended the mice-and-rats meaning, but I don't know what word related to rats or mice might have a similar meaning to "rootkit".
EDIT: Found it. He's referring to the acronym RAT meaning "Remote Access Trojan" (or, if actually intended, Remote Administration Tool).
probably trojan or malware?
Since muridae is the family of rodents that includes rats and mice, I believe he's referring to a RAT, a Remote Access Trojan. Something that functions rather like https://hunt.io/malware-families/reversessh or other similar malware, in other words.
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.
> ”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.)
i got tired of vscode always complaining about sth. I am liking neovim and Jetbrains IDEs, these never gave me any headache.
I'm still on SublimeText, which is old, and a pain in the ass, but at least is not being actively enshittified.
I'm still in SublimeText, which is fast, and does everything I need. Including not being a programming agent.
Moreover, it explicitly breaks in VSCodium and no good alternatives exist.
Not sure what you consider "no good" alternatives. jeanp413.open-remote-ssh[0] has worked flawlessly. It's the first or second search hit in the extension manager for "ssh". It's a fork of Microsoft's previous extension before the proprietarized it.
0: https://open-vsx.org/extension/jeanp413/open-remote-ssh
I very much dislike this extension because it uses a built-in ssh client that is far from feature complete and does a lot of reinventing the wheel. Microsoft's extension uses the system ssh binary, as does https://open-vsx.org/extension/aergic/zygos-vscodium which I much prefer. After discovering the latter, I uninstalled VSCode and have fully moved to VSCodium.
1 reply →
See https://open-vsx.org/extension/aergic/zygos-vscodium
You say that like it's a bad thing; I narrowly escaped serious use of VSCode thanks to this fact.
Take zed for a spin
I should call my dev machine the Fly Machine too
> 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’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
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.
As does the no AI fork, Gram.
Is this Gram capable of running on old macs?
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]
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 difference is that there is an SSH agent at all, whereas Emacs just uses the built-in Bourne shell.
Some people get an icky feeling where remote editing tools change the remote filesystem in any way that is not explicitly done by the user. A binary installation of Node is extra extra icky. (I don’t have Node installed anywhere on my computers; I avoid JS if possible and if not I prefer Deno.)
No, with TRAMP its a one way thing. The remote side can't wander around the local side at all, at least from my understanding of TRAMP. So it's no the same at all.
Wait, you mean that with the VS Code protocol, the remote side can send the commands to my local VS Code, making it do all kinds of funny stuff? Seriously? That's not really obvious from TFA at all and mostly reads as their unease with running somewhat opaque piece of software at the remote written for Node instead of presumably well-maintained bunch of sh scripts (a very interesting supposition IMHO).
> basically the same things that Tramp could do as well?
Yes, just much faster. At the cost of a proprietary binary blob on the remote end, whereas tramp works with bare sh/bash.
However there's now tramp-rpc, which is tramp but talks to a Rust client on the remote side, and that makes Emacs even faster than vscode-over-ssh.
Don't know why you are being downvoted, this is how a lot of clients do it - Jetbrains does the same thing as well.
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.
It doesn’t use an AI agent.
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.