I don't see any reasonable alternatives that can support what VScode does, like running extensions that aren't installed locally. Maybe those features aren't something you want, but they're part of the product feature set.

I believe extensions are actually installed on the host itself! At least when I use vs code remotely it shows "install on xxx" for each extension if I haven't installed it yet

Exactly. You can use extensions without even installing them locally. They're installed on the host.

Now imagine your host is a rented VM that you throw away after use.

It’s not clear to me, are these issues on the local or remote vs code instance? If remote, I understand elisp tramp is a lighter touch as far as dependencies go, but is the attack surface all that different? (That is, does the remote node binary have any permissions a user running arbitrary ssh clans wouldn’t?)

The OPs goal was to give an llm keys the kingdom on an ephemeral/throwaway virtual machine, are they saying the sockets opened up by the agent allow it to fiddle with the developer machine it’s meant to be isolated from?

Emacs Tramp just uses whatever SSH access you already have to a remote host, to copy files back and forth. It may use scp or sftp if the remote host advertises the protocol, but it does not install anything or invent any of its own protocols.

Now I'm wondering if you could inject an emacs lisp interpreter onto the remote machine. There are exploit frameworks that do something similar.

Whether such a thing should ever be written is a completely different question, of course.

tramp doesn't require running anything on the remote server, it's more like using sshfs.

But if you find an exploit that will run by simply editing a file in emacs, you could put that file on the server and

Yeah, I know. I'm not talking about tramp. What I'm saying is that you could do precisely the same thing vscode does, probably without adding any new code to emacs, as long as the client and server architectures matched. The client would just send its own elisp interpreter across the wire and run it, giving itself a remote repl you could have it run anything in.

That would, of course, be just as terrible an idea as when vscode does it.

One perspective is to think of these as things that a modern OS should provide as a standardized feature, and VSCode is just working around the fact they don't exist. It's crazy to think about but the kernel itself could have a webserver (or other protocol) with encryption and auth that let you directly control the entire machine through EBPF. It could be an entirely different paradigm for client/server remoting. Also a security hole you could drive a death star through.

You can have a standardised feature set, without sticking everything into the kernel.

I'm all for the former, but the latter is unnecessary.

A rootkit built right into the kernel? And apparently this is okay because it's "encrypted"? (Aka impossible to diagnose or monitor.)

Yikes.