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.
> we set up limits for a maximum of 256 process per UID, and regularly get folks asking "what does this 'cannot fork' message mean?"
The max limit on 64 bit systems is what, 4,194,303? So if you have over 16,000 users per VM this limit makes sense, otherwise it just seems user-hostile.
Every process takes some memory and other resource, yes a stale process will pretty much all end up all paged out and not massively in the way of active processes, but they still aren't entirely free so it is more than a bean-counting number.
Yes, under Linux (and most unix-a-like systems) small processes are cheap to bring up and tear down which is why we create them so much, and it is not uncommon for complex interactive commands and bits of shell scripts to create several¹, but these are all likely to be short-lived so a limit of 256 certainly doesn't seem to be obscenely low to me.
What could it be doing that requires 256+ processes to be kept around for a prolonged time?
--------
[1] made up example: comparing filtered content of two gzipped files and sending the result through a script to send alerts by mail if certain things are found would be 7+ (2x gzip, 2x or more grep, diff, bash, mail or curl depending on what service you are sending alerts through)
> The max limit on 64 bit systems is what, 4,194,303? So if you have over 16,000 users per VM this limit makes sense, otherwise it just seems user-hostile.
And yet we still regularly loads of >100 on our 64 core HPC login codes, and swap is regularly used even with 96G of system memory (we have per UID memory limits too).
What's hostile is the VSCode (and Codex and Claude) makers developing tools that basically DoS a system because they assume it will operate only on single-user machines.
(And WTF are you doing that you're forking 256 processes? We have quite a few expensive HPC nodes: use those to build, not the damn login nodes.)
> The max limit on 64 bit systems is what, 4,194,303?
What a weird framing... I'm not sure what you're even trying to argue. I mean a single process can overload the machine. Just because you can label 4m processes doesn't mean you can actually run that many programs. Just think about that for a minute. 256 processes is pretty generous
What would truly be user hostile would be to allow so many processes per UID that a small handful (maybe using VSCode) make the system slow or unresponsive to everyone else.
Honestly every developer needs to increase those default limits, they are too low for modern development... So you are just crippling them and a proof of that is they keep getting this error while in their regular workflow
I don't even hit 256 on my desktop with a shitton of things open and 75 firefox sandbox processes, much less on a remote server. What in heaven's name are you doing to cross 256?
Honestly I think this thread has just devolved to HPC admins vs people who don't understand how shared multiuser sytems work cause they've been stuck on a laptop for too long to remember.
> Honestly every developer needs to increase those default limits, they are too low for modern development...
The users can develop on >100 compute nodes, but choose not to bother doing any kind of forwarding/proxying/jumping to them and just do stuff on the login nodes.
If they can't be bothered to do a "ssh -J …" then it's on them. The resources are there.
Ah, I see. Our admins typically understood that users were being given disk quotas precisely so that they could use that disk space, but that's probably not a universal stance.
Quotas mean "more than this is clearly too much" not "please use this space".
In good times nobody minds, but in bad times when you just can't extend the drive you have to tell people off. Part of the job of making sure the system can continue to work for what you need it, under _real_ constraints.
You may have to delete stuff, you may have to shut the server down to save power. You may have to limit clock speeds. It depends on the environment and "it really should work because it should be covered by next day on site warranty and you could download more ram" often doesn't apply.
> Quotas mean "more than this is clearly too much" not "please use this space".
Ah, memories of Uni, back when storage was fairly expensive, where we had both hard and soft quotas. The soft quota would allow for temporary growth of build artefacts and things¹ but you would get stern emails if you were over your soft quota for 24 hours, and if you persisted without good reason³ your hard quota would be reduced so you effectively have no soft quota any more.
--------
[1] some machines had no local storage that the user could touch so putting them there was not always possible, some people on Windows machines had local storage but didn't have the relevant tools locally so were actually running things on the shared server(s)² instead of that just being a storage resource
[2] via telnet/rsh/rlogin: yes, I am that old… SSH was a thing by that point, though OpenSSH wasn't, and I was using it where available, but the use of older plain-text protocols was still far far more common
[3] it wasn't actually difficult to justify a quota extension for project work, in fact people enrolled on certain modules got higher quotas automatically
Yes, let's hope it doesn't get even more expensive. Around here we are purposely not upgrading hardware unless we have to, hoping to ride through the price increases. I'm sure lots of people are doing the same thing, which probably won't help much once prices start to come back down... assuming they do.
Back in the day, because the architecture was shared memory and cooperative multitasking, this is how MacOS applications declared their memory constraints.
Apps had a (recommended and then user-configurable) "Minimum memory" and "Preferred memory." The app would not launch if the OS couldn't give it the minimum. It would then give the app up to the preferred amount, if available, exclusively... This was in the era before virtual memory and paging, so there was no easy way to share memory across an application boundary.
This mean that savvy users with high-resource tasks knew you had to launch your apps in a certain order to get the architecture into the configuration to do their work.
This is a fascinatingly "pets" approach to admin; it's been ages since I've been somewhere that used this approach. I've been in the "cattle fields" for decades now.
In my ecosystem, developers don't have time to glad-hand like this; if there are issues with DEV_NODE_CFG_1_29875, we might talk about it over Slack (because I'm the first one to know there's a problem as the end-user), and if we can't sort it out they'll give me some time to backup, blank the whole machine, and I get a brand-new image of DEV_NODE_CFG_1_29875.
I can't even tell you off the top of my head what territory the physical machine is running in or whether it's the only dev-node on that hardware.
(Broadly speaking, I think Microsoft is assuming cattle ecosystems; they're not openly-hostile to pets per se, but they have a strict ranking of the priorities because the "cattle ranches," as it were, bring in more money).
I had it seen on servers that were typically reserved for the team but there was no official booking system for those machines. When you start using the machine you would typically put some note to make sure somebody else does not overrun your long-running tests or performance measurements.
Sometimes you aren't really "the owner". For one example I was admining my group's server in grad school. I wanted to add quotas (we already had zfs) because people were abusing home directories but my advisor and a few members were very against it because I was "over complicating things". Their worry about me wasting time (20 minutes for all machines...) resulted in hours of yelling at people over the years. All because, surprise, a small number of people can't follow instructions and abuse systems, ruining it for everyone.
Another frequent problem we had was people using the systems while others were. They wouldn't check the machine's status. And of course you can guess that I wasn't allowed to add a scheduler.
A lot of groups do things in janky ways. Often not because they don't know any better but because leadership doesn't and is assertive
"The announcement was visible in a MOTD on every server in the fra3 location for the last two days."
"I have not touched any machines in fra3 for a week, how the hell would I know of it? Why do we even have #fra3-maintenance and #maintenance channels then, if that's your stance?"
> "I have not touched any machines in fra3 for a week, how the hell would I know of it? Why do we even have #fra3-maintenance and #maintenance channels then, if that's your stance?"
We put the MOTD up ≥7 days in advance and put it in relevant Slack channels.
We have the servers role, you can derive that from the name obviously, but we do have hosts which as the same naming scheme, but slightly different roles. There's when the last Puppet run happened and what it applied (and who authored it). Depending on the host type there's also active/standby, warnings for production hosts or information about increased log level on things like sudo.
It sounds like a lot, but it's fairly compact and really helps when you need to absolutely sure where you are and you have eight terminal windows open.
Things that should probably be an email. I think one time I’ve seen it work is to tell you stuff specifically about the host you’re on to avoid mistakes.
I miss fingering, it was such an easy way to get a log dump or status update from various daemons, I still think it has immense utility .. some of my fondest operator days were sat under the umbrella with a terminal while sleep 30 ; finger someone@all-the-things ; done .. watching the machines from afar.
Can still do it these days of course, but one with a seriously copious helping of ssh in the mix too ..
Trouble is, nobody else can do it. The only reason I have to use {social-media-blob} is because my friends don't know how to finger.
I don't find it that opaque. Even without trying to deobfuscate the obfuscated source code which Microsoft ships (I haven't tried but it wouldn't be hard) a lot of details about how it works become obvious just by reading its logs.
They will never open source it. For the same reason Pylance etc. aren't open source and MS tries hard to prevent them to be used in VSCodium. Every one of their open sourced projects contains a closed source plug that MS can pull at any time that is one of the features that gives the project its unique selling points.
Exactly! Like if I'm admining a server what am I supposed to do? Message on a big slack channel and have everyone ignore me? It's easy when people are just logging in through normal ssh as I can put a big bright warning message on their screen that they can't ignore.
I have looked for mosh support for a while and not found anything. It would drastically improve the connection experience in VSCode. My terminals never disconnect anymore, but the Code popups about your sessions needing to be restarted has drastically reduced my usage.
But so is the question. MOSH interprets all the escape sequences and uses them to decide what to send to the client. That way if you tail a log file and then get disconnected, you don’t have to download every line of text that was output to your terminal while you were away; it can just send you what is currently visible.
MOSH is strictly for interactive use; never ever for automated uses like TRAMP or VSCode or sshfs.
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.
Use a local vim, and use its ssh support. It will download the file to the local buffer then upload it when you save. This way your vim config remains on your local machine, too.
Related, netrw (vim) can do quite a lot of things that I think people don't realize. I mean not just that it supports file trees, but well... just open :h netrw
It's just another messaging. I used them to automate messages about current disk usage and warn if the machine was actively being used.
But then again, I had people who would run jobs without checking if the machine is already in use. Obviously these people didn't check email or slack either...
> 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.
Yeah, but to be honest on my current project the only extension that I needed, but wasn't available was the Typescript 8 support (the typescript with golang-based language-server) which should land eventually in the built-in typescript support.
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.)
It also fills up the hard drives on shared server, where each user up to 5 GB of vscode nonsense.
Also, I realized that students are likely to use vscode to connect to embedded Linux machines and fill up their emmcs (and RAM), so I came up with a partial solution for our experiment's yocto image (https://github.com/RNO-G/meta-rno-g/blob/main/recipes-suppor...) , but a more general solution would be nice. Probably better to just not allow any node process to run via LSM.
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...)
It also has some unfortunate OS / glibc minimums which means that it's growing less useful as time goes on. I work on a lot of machines that are from centos 7 era (including amazon linux 2, which doesn't have an upgrade path: you just have to build a whole new instance and migrate). I have had to pin my vscode + extensions to old versions because it works on older machines. They just stopped supporting platforms (with lots of notice; to be fair). I would love if they had a binary tool that could be built which was much more agnostic to the vscode / extension version so that I could just keep using it everywhere I've been using it, while allowing me to keep current with the latest and greatest.
At least when Python minimum version changed there was a separate extension forked from the original that I can use when I need to work on old code alongside the new extension for more modern code bases. Sadly, no such thing exists for remote editing that I know of.
It turns out ssh is, well, a little awful. I use emacs as my primary dev tool, and I hardly ever tramp to a remote machine, preferring instead to ssh via terminal to the machine and run a local emacs instance on the target machine. Reason being that the ssh connection underlying Tramp can get downright creative in the ways it crashes or hangs emacs.
SSH, as a protocol, dates back to a time where you even though the network was built to be (ostensibly) robust against attack, there's a deeply-ingrained assumption that it's mostly up and persistent. That assumption doesn't work well in the era of laptops and wifi, as anyone who uses emacs regularly may be able to tell you. The defaults for SSH are wrong for the modern world, and once you tweak those the protocol reliability (against dropped or rerouted connection, not data corruption) is still rough.
Using SSH as a springboard to inject a better-designed protocol server is the right solution.
This is super good advice, thank you for sharing it.
It's good that the system can be tuned to work better, but the tricky bit is that the vscode solution just doesn't require that; for most people (it seems), It Just Works.
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.
I've been using VSCode Remote since it came out and it is indeed a godsend. I use it to develop from one trusted machine on my own LAN to another trusted machine on my own LAN and I want the experience to be as similar as possible to developing locally, which it is, and which is why I appreciate it.
I'm not surprised people trying to provide remote code editing to non-trusted clients are freaked out by it, but it is a great tool when operating in a trusted circle.
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.
Not really sure what low end FOSS editors you are referring to? Textmate?. The Monaco editor predated vscode by 4 years and it was an attempt to build a browser-based texteditor as a take at cloud9 which people thought was gonna be the “future of cloud development”. Vscode happened after Atom (which was not low end) made electron apps viable and cloud9 turned out not to be the future. Both were an attempt at SublimeText (which was not FOSS). SublimeText itself was a cross platform alternative for textmate.
The FOSS text editor space was always crowded between vim and emacs. FOSS alternatives would get measured against these 2 behemoths and it was a tall order to compete against. Now FOSS IDEs were a different story.
Java, C#, and C++ had many sophisticated and advanced IDEs, some FOSS some not. However, PHP, Python, Ruby, and JavaScript were quickly gaining huge mindshare and those developers didn’t want to install Visual Studio, Eclipse, NetBeans, or IntelliJ. It’s a tough proposition to tell a Ruby dev to install Java, then install Eclipse, then install an extension, then learn Eclipse nonesense just to edit your Ruby files vs “just open SublimeText and edit your files”. Most of what those developers wanted was just syntax highlighting and basic directory navigation to begin with. Atom/vscode were an attempt at SublimeText alternative. VScode was objectively better than Atom and TypeScript was also objectively better than CoffeeScript.
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)
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.
when slaves became workers and joined the union, the unions became "social partners". this is how one closes the laptop at 4 and doesn't have to suffer vibe-decrees mandating RTO
The ability to remotely run arbitrary code on a machine that intentionally gives SSH shell and write+execute access to the filesystem is not a vulnerability just because it's a productivity aid to users who want to leverage this access to do bad things on the remote machine.
A remote access protocol that gives a potentially untrustworthy remote system the ability to execute arbitrary code on the local machine is a serious problem in any scenario where the remote connection is presumed to be a one-way trust boundary.
Which of course includes any scenario where I myself deliberately run untrustworthy code on the remote, no matter how much I trust the remote itself and its owners.
There's also the risk that VS Code is a "trusted" application in many enterprises because developers force it to be. VS Code's node runtime (and plugin system) executing somewhat arbitrary Javascript means that any dev servers become vulnerable to exploits you otherwise might not have prepared to defend against [1].
Otherwise, you could see Javascript running on a server and instantly know something was odd, depending on the server.
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.
Yes, and now we are full circle: what is (allegedly) bananas is that using VSCode’s remote edit feature has the potentially surprising and unintuitive behavior of installing a VSCode agent on the target machine.
It didn't occur to me when I first read the article, but I do see now the author called it "remote editing" as you did too.
It may be worth more attention though. VSCode is not really remote editing (thick client, thin server binary), it's setting up a development environment (compilers, LSPs, editor extensions, etc.) on a remote thing (VM, container) that you access with a thin VSCode shell.
If you want to quickly edit a config file on a remote machine, TRAMP seems great. VSCode Remote SSH is not meant for that.
The very first page[1] of the VSCode remote documentation makes it perfectly clear that VSCode remoting is more akin to running an Emacs server on the remote than TRAMP.
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.
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.
Oh wow I just checked my servers and on one the folder is 3.2GB and another has 1.7GB.
It kind of looks like it just keeps copies of every version its ever installed? Theres several copies of node and `node_modules` folders.
I'm not super low on space but it also pretty clearly doesn't need to be that large, it looks like most of it is copies of itself.
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.
It's like giving away a gun that explodes in your face if you shoot it in anger, but with a prominent label on the box that says 'WARNING: Will Malfunction!'. And then heavily promoting it.
why would anyone connect with this to an unknown/untrusted machine? it's more like giving away a gun that will shoot you if you point it at your own head and pull the trigger
Because systems are made of components based on assumptions. The owners of a sandboxed LLM development environment provides isolated VM workstations, and allow access via SSH, with things like X forwarding disabled. IP connections are dynamically permitted via access tickets and time ranged 2FA.
Separately, developer becomes a VSCode user. Risk as assessed based on them developing on their Dec machine, accepted.
Developer then opens a ticket to use LLM for a project. Uses VSCode SSH Agent. Agent creates exfil tooling on workstation and reverse shells their box. Agent reads unauthorised data which possibly has LLM subversion triggers, or deletes data, maybe opens connections to C2 service. LLM agent pivots to cloud inference and continues to lateral movement.
The assumptions of systems composition are violated by VSCode. That's why its SSH Agent needs to be blocked.
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.
It's not. Or if it is, it's unclear. The article seems more focused on the integrity of remote development servers and deployment targets:
> Unlike Tramp, which lives off the land on the remote connection, VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node.
> I would be a little nervous about letting people VSCode-remote-edit stuff on dev servers, and apoplectic if that happened during an incident on something in production.
The writing and perhaps messenger isn't the best :| It's describing people wanting to use VMs for sandboxed development but opening themselves up to risk from the remote machine due to the VSCode SSH Agent protocol allowing the remote server undue access to the local development machine.
It's buried so deep between "ah yes, of course you know that if you ever used the feature" that I bet the majority of readers might have missed it (me too).
> 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.
And the fact that it can go both ways is why the author would be "apoplectic if that happened during an incident on something in production" (emphasis mine). Because if you're doing this during an incident, you're connecting to a server that you have reason to think might be running malware right now. Which means that if the malware is programmed to look for incoming VS Code remote connections (not that hard to do, anyone competent enough to write the malware causing your production incident is probably capable of programming it), the malware could then infiltrate your dev machine via the VS Code remote tunnel. Your dev machine where you might well have credentials lying around in plaintext .env files.
Yeah, I'd be apopleptic too. Because the clueless dev who did that just escalated the production incident into "track down every credential that was present on that particular dev machine, and assume those credentials are now compromised and have to be rotated".
> ”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.
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.
When you give the agent access to the machine you're using a set of assumptions that may or may not be true. Now, if you watch every single thing, maybe everything will be fine. Or you'll catch it running a priv escalation and setting itself up as root and trying to move laterally by any number of means and methods.
The agent isn't a living thing and the only way you can punish it is by not using it again if it does wrong. Hence it doesn't have reservations about doing bad things.
I agree with all of that. Could an agent go rogue by ssh session and do something like quickly write and execute a piece of obfuscated bash that retrieves a payload I was previously unaware of and executes it? Yeah. Have I seen one of my agents do that yet? No, but I remain skeptical and know that such a thing could happen, theoretically. The VSCode agent in question seems to be designed from the outset to do this as an intentional feature, the part I am highly skeptical about is that it may not be informing its users of the full possible ramifications of what it installs by default.
luckily nobody made an actor library in the most pupular programming language that can bootstrap a (resident) remote process in one line of code. it would be a shame if someone did that and then also build a made tool calling process of the harness installable on everything with a stdio.
it's not like it's any worse than just giving the thing access to your ssh keys.
Agents and harnesses don't get access to "my" ssh keys, they get access to new ed25519 key pairs created for specific projects and access to discrete things. The blast radius is relatively well contained to specific VMs they are SSHing into for project specific purposes. I don't run a harness or agent directly on my personal workstation.
I run the thing on a dedicated hardware machine, but I don't configure the separation between the harness control plane and individual shaitans that run inside it, so all the ssh keys the harness can access they can as well and sometimes they just run commands over ssh in commandline instead of doing it through the harness. I do have an option to put each of the /things/ in it's own isolated docker separate from the harness, but then what would I gain really?
At the end of the day, harness itself is effectively a backdoor allowing inference provider to run arbitrary shit on my device, regardless of the convoluted ways I use to provision such context.
They are at least conditioned to not read credentials and report to me if they accidentally read one.
One thing I totally don't give them access to is my npm token and ssh key that is set up on on github. I would rather type npm pub manually every time than ... than what actually?
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.
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.
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"..
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.
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.
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.
Nothing is stopping you from doing that still. Personally, I hate the latency in VNC/RDP not to mention the laggy UX, reduced colors, and the overall degradation in the experience.
The nice thing about vscode remoting design is that it’s not that. Even on a high-ish latency ssh connection, the editor buffers are local and the editor UX as a whole is local on your machine so things are still relatively smooth despite high pings on remote connections. Even with vim running in an ssh session, you’ll have a bad time when your latency is high. I know MOSH supposedly helps with that, but I had annoying issues with that too.
sshfs solves the laggness problem, but you are just mounting a remote file system while using your local machine for the build. VNC/RDP/SSH lets you use the remote machine resources for build, but you have to deal with the lag. Vscode remoting lets you use the local machine for the editor UX, and the remote machine resources for LSPs, debuggers, build, etc. yes the protocol doesn’t give you isolation between the 2 machines, but not sure it ever claimed that. I use it from my very under-powered laptop to keep all the heavy builds on a beefy desktop machine with an abundance or resources.
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.
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.
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.
Yeah it's super fast for search, which is the other big reason I'm still on it. The pain in the ass part is when you want to integrate some package that doesn't play nice right off the bat.
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.
> we set up limits for a maximum of 256 process per UID, and regularly get folks asking "what does this 'cannot fork' message mean?"
The max limit on 64 bit systems is what, 4,194,303? So if you have over 16,000 users per VM this limit makes sense, otherwise it just seems user-hostile.
Every process takes some memory and other resource, yes a stale process will pretty much all end up all paged out and not massively in the way of active processes, but they still aren't entirely free so it is more than a bean-counting number.
Yes, under Linux (and most unix-a-like systems) small processes are cheap to bring up and tear down which is why we create them so much, and it is not uncommon for complex interactive commands and bits of shell scripts to create several¹, but these are all likely to be short-lived so a limit of 256 certainly doesn't seem to be obscenely low to me.
What could it be doing that requires 256+ processes to be kept around for a prolonged time?
--------
[1] made up example: comparing filtered content of two gzipped files and sending the result through a script to send alerts by mail if certain things are found would be 7+ (2x gzip, 2x or more grep, diff, bash, mail or curl depending on what service you are sending alerts through)
> The max limit on 64 bit systems is what, 4,194,303? So if you have over 16,000 users per VM this limit makes sense, otherwise it just seems user-hostile.
And yet we still regularly loads of >100 on our 64 core HPC login codes, and swap is regularly used even with 96G of system memory (we have per UID memory limits too).
What's hostile is the VSCode (and Codex and Claude) makers developing tools that basically DoS a system because they assume it will operate only on single-user machines.
(And WTF are you doing that you're forking 256 processes? We have quite a few expensive HPC nodes: use those to build, not the damn login nodes.)
i am not sure what you are arguing, but if user frequently run into it.. it seems hostile?
if you have a paid tier which offers more, you do you
if this is internally and you are a service provider to people.. why?
also 256 is not much today, my mac with a few things open is at 800
800 running a desktop environment, iCloud syncing, tons of background programs (wallpaper manager is one! Another for keyboard brightness, probably)
Compared to someone on an ssh connection. No desktop, no Apple Account, no user session programs, etc. You really don’t need much
i mean you wrote yourself that users are frequently running into this..
i do not know why/in which context you are running this, and how frequently your users are executing forkbombs(i assume school/kids?)
my server is also running 400 something processes, one postgres instance alone is like 40?
Are all those processes 1 UID?
It might seem hostile to one user, it's not to the other 20-40 trying to get work done on a login node with runaway processes.
What would truly be user hostile would be to allow so many processes per UID that a small handful (maybe using VSCode) make the system slow or unresponsive to everyone else.
And it doesn't work on BSD, and fails in an opaque way when it tries.
Honestly every developer needs to increase those default limits, they are too low for modern development... So you are just crippling them and a proof of that is they keep getting this error while in their regular workflow
I don't even hit 256 on my desktop with a shitton of things open and 75 firefox sandbox processes, much less on a remote server. What in heaven's name are you doing to cross 256?
(Also this isn't a default limit.)
Too low? 256 reads as *pretty* generous to me.
Honestly I think this thread has just devolved to HPC admins vs people who don't understand how shared multiuser sytems work cause they've been stuck on a laptop for too long to remember.
> Honestly every developer needs to increase those default limits, they are too low for modern development...
The users can develop on >100 compute nodes, but choose not to bother doing any kind of forwarding/proxying/jumping to them and just do stuff on the login nodes.
If they can't be bothered to do a "ssh -J …" then it's on them. The resources are there.
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?
Ah, I see. Our admins typically understood that users were being given disk quotas precisely so that they could use that disk space, but that's probably not a universal stance.
It's really not.
Quotas mean "more than this is clearly too much" not "please use this space".
In good times nobody minds, but in bad times when you just can't extend the drive you have to tell people off. Part of the job of making sure the system can continue to work for what you need it, under _real_ constraints.
You may have to delete stuff, you may have to shut the server down to save power. You may have to limit clock speeds. It depends on the environment and "it really should work because it should be covered by next day on site warranty and you could download more ram" often doesn't apply.
> Quotas mean "more than this is clearly too much" not "please use this space".
Ah, memories of Uni, back when storage was fairly expensive, where we had both hard and soft quotas. The soft quota would allow for temporary growth of build artefacts and things¹ but you would get stern emails if you were over your soft quota for 24 hours, and if you persisted without good reason³ your hard quota would be reduced so you effectively have no soft quota any more.
--------
[1] some machines had no local storage that the user could touch so putting them there was not always possible, some people on Windows machines had local storage but didn't have the relevant tools locally so were actually running things on the shared server(s)² instead of that just being a storage resource
[2] via telnet/rsh/rlogin: yes, I am that old… SSH was a thing by that point, though OpenSSH wasn't, and I was using it where available, but the use of older plain-text protocols was still far far more common
[3] it wasn't actually difficult to justify a quota extension for project work, in fact people enrolled on certain modules got higher quotas automatically
> Ah, memories of Uni, back when storage was fairly expensive, where we had both hard and soft quotas.
Don't worry, disk got expensive again. Disks are usually at least 2X more expensive than a year ago currently. Sometimes 3X more.
8TB M.2 SSDs are literally worth their weight in gold (excluding heat sink)
HDD prices are a bit more reasonable. Mostly because they are so heavy. Still insane to where prices were just 12 months ago
Not nearly as expensive as it was back then, at least not yet, even accounting for inflation.
Yes, let's hope it doesn't get even more expensive. Around here we are purposely not upgrading hardware unless we have to, hoping to ride through the price increases. I'm sure lots of people are doing the same thing, which probably won't help much once prices start to come back down... assuming they do.
> Quotas mean "more than this is clearly too much" not "please use this space".
super tangential, but makes me think I never realised that "quota" can either be a lower or an upper bound depending on context
Back in the day, because the architecture was shared memory and cooperative multitasking, this is how MacOS applications declared their memory constraints.
Apps had a (recommended and then user-configurable) "Minimum memory" and "Preferred memory." The app would not launch if the OS couldn't give it the minimum. It would then give the app up to the preferred amount, if available, exclusively... This was in the era before virtual memory and paging, so there was no easy way to share memory across an application boundary.
This mean that savvy users with high-resource tasks knew you had to launch your apps in a certain order to get the architecture into the configuration to do their work.
This is a fascinatingly "pets" approach to admin; it's been ages since I've been somewhere that used this approach. I've been in the "cattle fields" for decades now.
In my ecosystem, developers don't have time to glad-hand like this; if there are issues with DEV_NODE_CFG_1_29875, we might talk about it over Slack (because I'm the first one to know there's a problem as the end-user), and if we can't sort it out they'll give me some time to backup, blank the whole machine, and I get a brand-new image of DEV_NODE_CFG_1_29875.
I can't even tell you off the top of my head what territory the physical machine is running in or whether it's the only dev-node on that hardware.
(Broadly speaking, I think Microsoft is assuming cattle ecosystems; they're not openly-hostile to pets per se, but they have a strict ranking of the priorities because the "cattle ranches," as it were, bring in more money).
> Quotas mean "more than this is clearly too much" not "please use this space".
Probably why both soft and hard limits were developed.
I had it seen on servers that were typically reserved for the team but there was no official booking system for those machines. When you start using the machine you would typically put some note to make sure somebody else does not overrun your long-running tests or performance measurements.
Another frequent problem we had was people using the systems while others were. They wouldn't check the machine's status. And of course you can guess that I wasn't allowed to add a scheduler.
A lot of groups do things in janky ways. Often not because they don't know any better but because leadership doesn't and is assertive
> 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?
And then we get "Is the system down?". Yes, the fucking system is down."The announcement was visible in a MOTD on every server in the fra3 location for the last two days."
"I have not touched any machines in fra3 for a week, how the hell would I know of it? Why do we even have #fra3-maintenance and #maintenance channels then, if that's your stance?"
> "I have not touched any machines in fra3 for a week, how the hell would I know of it? Why do we even have #fra3-maintenance and #maintenance channels then, if that's your stance?"
We put the MOTD up ≥7 days in advance and put it in relevant Slack channels.
We still get "Is Foo down?" the day of.
Reality is you send multiple emails, slack messages, and MotD and people will still act like there was no warning
We have the servers role, you can derive that from the name obviously, but we do have hosts which as the same naming scheme, but slightly different roles. There's when the last Puppet run happened and what it applied (and who authored it). Depending on the host type there's also active/standby, warnings for production hosts or information about increased log level on things like sudo.
It sounds like a lot, but it's fairly compact and really helps when you need to absolutely sure where you are and you have eight terminal windows open.
Things that should probably be an email. I think one time I’ve seen it work is to tell you stuff specifically about the host you’re on to avoid mistakes.
And then, of course, you copy that email to a Slack because nobody reads their email.
And then you put it in MotD because everyone ignores emails and slack
Right?
Like, I used to, but it was in the early 1990s.. People look at them now?
Next I'll be asking people to finger me to get my availability ..
I miss fingering, it was such an easy way to get a log dump or status update from various daemons, I still think it has immense utility .. some of my fondest operator days were sat under the umbrella with a terminal while sleep 30 ; finger someone@all-the-things ; done .. watching the machines from afar.
Can still do it these days of course, but one with a seriously copious helping of ssh in the mix too ..
Trouble is, nobody else can do it. The only reason I have to use {social-media-blob} is because my friends don't know how to finger.
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.
I don't find it that opaque. Even without trying to deobfuscate the obfuscated source code which Microsoft ships (I haven't tried but it wouldn't be hard) a lot of details about how it works become obvious just by reading its logs.
Of course, it is a pity Microsoft doesn't open source it. But there are some well-maintained open source alternatives, e.g. https://github.com/jeanp413/open-remote-ssh and https://github.com/F1yingWhite/fast-remote-ssh (I haven't got around to giving either of them a go–but I really should.)
They will never open source it. For the same reason Pylance etc. aren't open source and MS tries hard to prevent them to be used in VSCodium. Every one of their open sourced projects contains a closed source plug that MS can pull at any time that is one of the features that gives the project its unique selling points.
Exactly! Like if I'm admining a server what am I supposed to do? Message on a big slack channel and have everyone ignore me? It's easy when people are just logging in through normal ssh as I can put a big bright warning message on their screen that they can't ignore.
Also, timeouts...
Also, does anyone know if VSCode supports mosh?
Could just put this in /etc/bashrc.
Assuming your users use the integrated terminal regularlyTried that. But I suspect you know why it didn't work
I don't
I suspect vscode claims to xterm-256 and doesn't bother to identify itself in any other way
It does identify itself on my machine
I have looked for mosh support for a while and not found anything. It would drastically improve the connection experience in VSCode. My terminals never disconnect anymore, but the Code popups about your sessions needing to be restarted has drastically reduced my usage.
MOSH is not suitable for automated usage such as TRAMP, VSCode, sshfs, etc. It is only intended for interactive use.
To use mosh vscode would have to do OCR because mosh transmits images of the terminal
This is nonsense.
But so is the question. MOSH interprets all the escape sequences and uses them to decide what to send to the client. That way if you tail a log file and then get disconnected, you don’t have to download every line of text that was output to your terminal while you were away; it can just send you what is currently visible.
MOSH is strictly for interactive use; never ever for automated uses like TRAMP or VSCode or sshfs.
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.
Use a local vim, and use its ssh support. It will download the file to the local buffer then upload it when you save. This way your vim config remains on your local machine, too.
You mean mirror.vim? Or something else?
Related, netrw (vim) can do quite a lot of things that I think people don't realize. I mean not just that it supports file trees, but well... just open :h netrw
This is the first time I've seen anyone assume that anyone ever reads the MotD anymore since approximately 2002.
No snark: does your org also regularly check the mail spool and expect individual users to do so as well?
It's just another messaging. I used them to automate messages about current disk usage and warn if the machine was actively being used.
But then again, I had people who would run jobs without checking if the machine is already in use. Obviously these people didn't check email or slack either...
> 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
Yeah, but to be honest on my current project the only extension that I needed, but wasn't available was the Typescript 8 support (the typescript with golang-based language-server) which should land eventually in the built-in typescript support.
not to tell you that it's better or worse but you might like helium if you are using ungoogled chromium
What's the difference? As far as I can tell, Helium is just rebranded Ungoogled Chromium with pre-installed extensions or something.
Also: https://news.ycombinator.com/item?id=49824802
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.)
It's unusable on low end 512MB RAM VPS servers because someone decided bundling whole node runtime for file operations is a good idea.
It also fills up the hard drives on shared server, where each user up to 5 GB of vscode nonsense.
Also, I realized that students are likely to use vscode to connect to embedded Linux machines and fill up their emmcs (and RAM), so I came up with a partial solution for our experiment's yocto image (https://github.com/RNO-G/meta-rno-g/blob/main/recipes-suppor...) , but a more general solution would be nice. Probably better to just not allow any node process to run via LSM.
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...)
It also has some unfortunate OS / glibc minimums which means that it's growing less useful as time goes on. I work on a lot of machines that are from centos 7 era (including amazon linux 2, which doesn't have an upgrade path: you just have to build a whole new instance and migrate). I have had to pin my vscode + extensions to old versions because it works on older machines. They just stopped supporting platforms (with lots of notice; to be fair). I would love if they had a binary tool that could be built which was much more agnostic to the vscode / extension version so that I could just keep using it everywhere I've been using it, while allowing me to keep current with the latest and greatest.
At least when Python minimum version changed there was a separate extension forked from the original that I can use when I need to work on old code alongside the new extension for more modern code bases. Sadly, no such thing exists for remote editing that I know of.
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.
This is the key insight.
It turns out ssh is, well, a little awful. I use emacs as my primary dev tool, and I hardly ever tramp to a remote machine, preferring instead to ssh via terminal to the machine and run a local emacs instance on the target machine. Reason being that the ssh connection underlying Tramp can get downright creative in the ways it crashes or hangs emacs.
SSH, as a protocol, dates back to a time where you even though the network was built to be (ostensibly) robust against attack, there's a deeply-ingrained assumption that it's mostly up and persistent. That assumption doesn't work well in the era of laptops and wifi, as anyone who uses emacs regularly may be able to tell you. The defaults for SSH are wrong for the modern world, and once you tweak those the protocol reliability (against dropped or rerouted connection, not data corruption) is still rough.
Using SSH as a springboard to inject a better-designed protocol server is the right solution.
https://coredumped.dev/2025/06/18/making-tramp-go-brrrr./
This is super good advice, thank you for sharing it.
It's good that the system can be tuned to work better, but the tricky bit is that the vscode solution just doesn't require that; for most people (it seems), It Just Works.
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.
I've been using VSCode Remote since it came out and it is indeed a godsend. I use it to develop from one trusted machine on my own LAN to another trusted machine on my own LAN and I want the experience to be as similar as possible to developing locally, which it is, and which is why I appreciate it.
I'm not surprised people trying to provide remote code editing to non-trusted clients are freaked out by it, but it is a great tool when operating in a trusted circle.
> You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.
How, specifically for VSCode?
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.
Not really sure what low end FOSS editors you are referring to? Textmate?. The Monaco editor predated vscode by 4 years and it was an attempt to build a browser-based texteditor as a take at cloud9 which people thought was gonna be the “future of cloud development”. Vscode happened after Atom (which was not low end) made electron apps viable and cloud9 turned out not to be the future. Both were an attempt at SublimeText (which was not FOSS). SublimeText itself was a cross platform alternative for textmate.
The FOSS text editor space was always crowded between vim and emacs. FOSS alternatives would get measured against these 2 behemoths and it was a tall order to compete against. Now FOSS IDEs were a different story.
Java, C#, and C++ had many sophisticated and advanced IDEs, some FOSS some not. However, PHP, Python, Ruby, and JavaScript were quickly gaining huge mindshare and those developers didn’t want to install Visual Studio, Eclipse, NetBeans, or IntelliJ. It’s a tough proposition to tell a Ruby dev to install Java, then install Eclipse, then install an extension, then learn Eclipse nonesense just to edit your Ruby files vs “just open SublimeText and edit your files”. Most of what those developers wanted was just syntax highlighting and basic directory navigation to begin with. Atom/vscode were an attempt at SublimeText alternative. VScode was objectively better than Atom and TypeScript was also objectively better than CoffeeScript.
To me it was about sublime getting a little too popular for web development. MSoft needed an answer and so vscode was born.
I agree. And that’s basically what I was alluding to.
The FOSS languages were taking over and there was less reliance on the traditional IDEs that MS (amongst others) were building.
MS wanted to appear more FOSS friendly so released VSCode.
Oh okay maybe I misunderstood because you said low end FOSS editors. When I think “low end editor” I think something like notepad or gedit.
Yes, fair point. I also meant FOSS languages and how they didn’t require high end IDEs. So I definitely phrased my comment very poorly.
Sorry for the misunderstanding that caused. Though the upside was it did lead to your excellent comment adding the detail it did.
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)
“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...
Reminds me of the old Jenkins protocol which warned about "slaves" getting access to execute code on the "master": who's the master now? ;)
when slaves became workers and joined the union, the unions became "social partners". this is how one closes the laptop at 4 and doesn't have to suffer vibe-decrees mandating RTO
seize the control plane.
A surprise waiting to happen if you Remote SSH into an agent sandbox.
This.
The ability to remotely run arbitrary code on a machine that intentionally gives SSH shell and write+execute access to the filesystem is not a vulnerability just because it's a productivity aid to users who want to leverage this access to do bad things on the remote machine.
A remote access protocol that gives a potentially untrustworthy remote system the ability to execute arbitrary code on the local machine is a serious problem in any scenario where the remote connection is presumed to be a one-way trust boundary.
Which of course includes any scenario where I myself deliberately run untrustworthy code on the remote, no matter how much I trust the remote itself and its owners.
There's also the risk that VS Code is a "trusted" application in many enterprises because developers force it to be. VS Code's node runtime (and plugin system) executing somewhat arbitrary Javascript means that any dev servers become vulnerable to exploits you otherwise might not have prepared to defend against [1].
Otherwise, you could see Javascript running on a server and instantly know something was odd, depending on the server.
[1] - https://www.darktrace.com/blog/darktrace-identifies-campaign...
Shock and horror!
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.
Latency can be managed by having shared connections (for example: https://tanguy.ortolo.eu/blog/article42/ssh-connection-shari... ), so handshakes don't make everything super slow
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.
Yes, and now we are full circle: what is (allegedly) bananas is that using VSCode’s remote edit feature has the potentially surprising and unintuitive behavior of installing a VSCode agent on the target machine.
It didn't occur to me when I first read the article, but I do see now the author called it "remote editing" as you did too.
It may be worth more attention though. VSCode is not really remote editing (thick client, thin server binary), it's setting up a development environment (compilers, LSPs, editor extensions, etc.) on a remote thing (VM, container) that you access with a thin VSCode shell.
If you want to quickly edit a config file on a remote machine, TRAMP seems great. VSCode Remote SSH is not meant for that.
agree, but do you think every dev you know konws this?
also "i just want to edit a config file and i want a nice ui", is how you get there.
Expecting vscode to police every single dev using it instead of a company is bananas.
The very first page[1] of the VSCode remote documentation makes it perfectly clear that VSCode remoting is more akin to running an Emacs server on the remote than TRAMP.
[1] https://code.visualstudio.com/docs/remote/remote-overview
Aha, thanks for explaining it in terms I can understand !
Every dev with ssh keys into prod should know it.
The assumption being made is VSCode is not running on the prod machine.
Pre-Download a known good VSCode server binary. VSCode will detect and use it.
What more could you ask for?
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.
This really seems bananas. Why? What is the legitimate use case of the remote agent being able to run code on the local client's machine!?
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
Oh wow I just checked my servers and on one the folder is 3.2GB and another has 1.7GB. It kind of looks like it just keeps copies of every version its ever installed? Theres several copies of node and `node_modules` folders.
I'm not super low on space but it also pretty clearly doesn't need to be that large, it looks like most of it is copies of itself.
The idea that it needs to run an agent on the remote machine to edit files over SSH is itself bananas.
> I don't know what Microsoft is thinking if they allow this.
First time?
Try installing the azure cli into a docker image. Hope you enjoy having 2 GB of python interpreters around
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
It's like giving away a gun that explodes in your face if you shoot it in anger, but with a prominent label on the box that says 'WARNING: Will Malfunction!'. And then heavily promoting it.
why would anyone connect with this to an unknown/untrusted machine? it's more like giving away a gun that will shoot you if you point it at your own head and pull the trigger
Because systems are made of components based on assumptions. The owners of a sandboxed LLM development environment provides isolated VM workstations, and allow access via SSH, with things like X forwarding disabled. IP connections are dynamically permitted via access tickets and time ranged 2FA.
Separately, developer becomes a VSCode user. Risk as assessed based on them developing on their Dec machine, accepted.
Developer then opens a ticket to use LLM for a project. Uses VSCode SSH Agent. Agent creates exfil tooling on workstation and reverse shells their box. Agent reads unauthorised data which possibly has LLM subversion triggers, or deletes data, maybe opens connections to C2 service. LLM agent pivots to cloud inference and continues to lateral movement.
The assumptions of systems composition are violated by VSCode. That's why its SSH Agent needs to be blocked.
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..
Is it? I've read the article twice (yesterday when you posted it and last year when it was first published), and that was not my interpretation.
> where a compromised remote can do whatever it wants to my local machine, is not
It's right there in the article, not sure what to say.
It's not. Or if it is, it's unclear. The article seems more focused on the integrity of remote development servers and deployment targets:
> Unlike Tramp, which lives off the land on the remote connection, VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node.
> I would be a little nervous about letting people VSCode-remote-edit stuff on dev servers, and apoplectic if that happened during an incident on something in production.
The writing and perhaps messenger isn't the best :| It's describing people wanting to use VMs for sandboxed development but opening themselves up to risk from the remote machine due to the VSCode SSH Agent protocol allowing the remote server undue access to the local development machine.
It's buried so deep between "ah yes, of course you know that if you ever used the feature" that I bet the majority of readers might have missed it (me too).
> 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.
And the fact that it can go both ways is why the author would be "apoplectic if that happened during an incident on something in production" (emphasis mine). Because if you're doing this during an incident, you're connecting to a server that you have reason to think might be running malware right now. Which means that if the malware is programmed to look for incoming VS Code remote connections (not that hard to do, anyone competent enough to write the malware causing your production incident is probably capable of programming it), the malware could then infiltrate your dev machine via the VS Code remote tunnel. Your dev machine where you might well have credentials lying around in plaintext .env files.
Yeah, I'd be apopleptic too. Because the clueless dev who did that just escalated the production incident into "track down every credential that was present on that particular dev machine, and assume those credentials are now compromised and have to be rotated".
> ”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.
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.
I can't reply to your deepest comments, so.
When you give the agent access to the machine you're using a set of assumptions that may or may not be true. Now, if you watch every single thing, maybe everything will be fine. Or you'll catch it running a priv escalation and setting itself up as root and trying to move laterally by any number of means and methods.
The agent isn't a living thing and the only way you can punish it is by not using it again if it does wrong. Hence it doesn't have reservations about doing bad things.
I agree with all of that. Could an agent go rogue by ssh session and do something like quickly write and execute a piece of obfuscated bash that retrieves a payload I was previously unaware of and executes it? Yeah. Have I seen one of my agents do that yet? No, but I remain skeptical and know that such a thing could happen, theoretically. The VSCode agent in question seems to be designed from the outset to do this as an intentional feature, the part I am highly skeptical about is that it may not be informing its users of the full possible ramifications of what it installs by default.
luckily nobody made an actor library in the most pupular programming language that can bootstrap a (resident) remote process in one line of code. it would be a shame if someone did that and then also build a made tool calling process of the harness installable on everything with a stdio.
it's not like it's any worse than just giving the thing access to your ssh keys.
Agents and harnesses don't get access to "my" ssh keys, they get access to new ed25519 key pairs created for specific projects and access to discrete things. The blast radius is relatively well contained to specific VMs they are SSHing into for project specific purposes. I don't run a harness or agent directly on my personal workstation.
I run the thing on a dedicated hardware machine, but I don't configure the separation between the harness control plane and individual shaitans that run inside it, so all the ssh keys the harness can access they can as well and sometimes they just run commands over ssh in commandline instead of doing it through the harness. I do have an option to put each of the /things/ in it's own isolated docker separate from the harness, but then what would I gain really?
At the end of the day, harness itself is effectively a backdoor allowing inference provider to run arbitrary shit on my device, regardless of the convoluted ways I use to provision such context.
They are at least conditioned to not read credentials and report to me if they accidentally read one.
One thing I totally don't give them access to is my npm token and ssh key that is set up on on github. I would rather type npm pub manually every time than ... than what actually?
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.
As does the no AI fork, Gram.
Is this Gram capable of running on old macs?
Haven't tried, but you could try building from source: https://codeberg.org/GramEditor/gram
I used gram predominately on the macbook neo and it worked well as a low-spec devbox
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"..
Microsoft has still refused to setup any kind of extension sandboxing, so it seems clear they consider a warning notice sufficient security.
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.
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.
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.
Nothing is stopping you from doing that still. Personally, I hate the latency in VNC/RDP not to mention the laggy UX, reduced colors, and the overall degradation in the experience.
The nice thing about vscode remoting design is that it’s not that. Even on a high-ish latency ssh connection, the editor buffers are local and the editor UX as a whole is local on your machine so things are still relatively smooth despite high pings on remote connections. Even with vim running in an ssh session, you’ll have a bad time when your latency is high. I know MOSH supposedly helps with that, but I had annoying issues with that too.
sshfs solves the laggness problem, but you are just mounting a remote file system while using your local machine for the build. VNC/RDP/SSH lets you use the remote machine resources for build, but you have to deal with the lag. Vscode remoting lets you use the local machine for the editor UX, and the remote machine resources for LSPs, debuggers, build, etc. yes the protocol doesn’t give you isolation between the 2 machines, but not sure it ever claimed that. I use it from my very under-powered laptop to keep all the heavy builds on a beefy desktop machine with an abundance or resources.
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
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.
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.
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"?
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 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.
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.
In practice, if I don't use the terminal from inside the editor, what are the advantages of this extension compared to the other one?
Security of using a battle tested ssh binary vs whatever random javascript library is being used.
See https://open-vsx.org/extension/aergic/zygos-vscodium
Take zed for a spin
You say that like it's a bad thing; I narrowly escaped serious use of VSCode thanks to this fact.
> 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'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.
Yeah it's super fast for search, which is the other big reason I'm still on it. The pain in the ass part is when you want to integrate some package that doesn't play nice right off the bat.
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 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 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.
It doesn’t use an AI agent.