VSCode's SSH Agent Is Bananas

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.

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.

> ”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 part of VSCode's architecture is acceptable to me. The reverse direction, where a compromised remote can do whatever it wants to my local machine, is not.

> The agent runs over port-forwarded SSH. It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:

Wander around the filesystem

Edit arbitrary files

Launch its own shell PTY processes

Persist itself

Wait, could someone clarify which machine is being referred to here?

So in the author's setup, he runs VSCode (i.e. the front-end) on his dev laptop, which he wants to keep free of direct LLM access.

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

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

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

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

Is that it? That would be truly insane!

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

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