Top
Best
New

Posted by Rapzid 18 hours ago

VSCode's SSH Agent Is Bananas (2025)(fly.io)
271 points | 166 commentspage 4
psyclobe 16 hours ago|
Honestly now that I'm basically dictating ai on what to do I've really stopped using all guis. Terminal is all I need.
833dong 2 hours ago||
[flagged]
mayowaolajide 2 hours ago||
[flagged]
tvjdkbu 14 hours ago||
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ñ

KeplerBoy 17 hours ago||
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

bithammerthunde 15 hours ago||
Misguided post, as you can see when you consider what VSCode and SSH are for.
Joker_vD 17 hours ago||
> 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?

kccqzy 16 hours ago||
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.)

chlorion 14 hours ago|||
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.
Joker_vD 13 hours ago||
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).
woodada 17 hours ago|||
> 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.

hilariously 16 hours ago||
Don't know why you are being downvoted, this is how a lot of clients do it - Jetbrains does the same thing as well.
dleslie 17 hours ago||
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.

kstrauser 9 hours ago|
It doesn’t use an AI agent.
stwrt 10 hours ago|
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.