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

Shock and horror!

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.

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.

A surprise waiting to happen if you Remote SSH into an agent sandbox.

Yeah this is the right architecture for remote editing with remote tools. It works really well. (There are longstanding bugs around reconnection when the SSH connection is broken but that's not the fault of the architecture.)

Nothing has changed as far as the insecurity the article has outlined.

The problem is the remote host has control over local host through the protocol.

I suspect vscode claims to xterm-256 and doesn't bother to identify itself in any other way

  cat /etc/motd >&2

please

MOSH is not suitable for automated usage such as TRAMP, VSCode, sshfs, etc. It is only intended for interactive use.

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.

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.

And it doesn't work on BSD, and fails in an opaque way when it tries.

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)

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

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

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.

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.

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.

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.

Well, it's better than JetBrains Remote Development which opens a new SSH connection every second.

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)

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.

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.

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

Also: https://news.ycombinator.com/item?id=49824802

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

You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.

How, specifically for VSCode?

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

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

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

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

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.

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

You say that like it's a bad thing; I narrowly escaped serious use of VSCode thanks to this fact.

Take zed for a spin

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

See https://open-vsx.org/extension/aergic/zygos-vscodium

It doesn’t use an AI agent.

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.

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

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

The assumption being made is VSCode is not running on the prod 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.

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.

Pre-Download a known good VSCode server binary. VSCode will detect and use it.

What more could you ask for?

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.

Yeah, I learned how it worked when I made the mistake of trying to use it to develop on a Raspberry Pi, where it filled the disk and crashed/hung the Pi by using all the RAM until it started using swap. Fell back to local with an sshfs mount instead.

Using Remote-SSH opens a connection between your local machine and the remote. Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.

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

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:

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.

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.

Is this Gram capable of running on old macs?

I’m currently experimenting with running:

- neovim

- in VS Code [1]

- in the browser

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

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

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

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

I should call my dev machine the Fly Machine too

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.

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

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

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.

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

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.

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

Microsoft has still refused to setup any kind of extension sandboxing, so it seems clear they consider a warning notice sufficient security.

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

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.

440hz

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

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ñ

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

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

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

I'm still in SublimeText, which is fast, and does everything I need. Including not being a programming agent.

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.

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

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.

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.

I don't know what Microsoft is thinking if they allow this.

First time?