Comment by xg15 | Hacker News Reader

Comment by xg15 | Hacker News Reader

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

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

Reply on news.ycombinator.com