[exasperaited]

Wrote this late at night and didn’t explain what I meant by X11 view.

I was thinking back to running X sessions on remote machines, sending for example a text editor view back across the network to my desktop.

VSCode remote feels to my fiftysomething brain to be logically quite like that, only you are sending the display back from the remote worker using web techniques, and rather than to a display manager, you are sending it back into the shell of an editor, so it appears to be largely indistinguishable from a session running on your local machine.

[Magnolia9438]

Maybe I’m misunderstanding, but I think what you want already exists as VSCodes remote SSH tunnel port forwarding (not the one that makes it publicly accessible).

Startup a dev server on the remote machine and forward the port to localhost. It should now be accessible via http://localhost:[port] on your local machine in the browser or any application, as if it’s running locally.

I find it’s very useful for also for interacting with DBs/Redis. Just forward the port your DB communicates on and use whatever client on your local machine to interact with it.

As far as I know this works with any service that communicates via TCP

[exasperaited]

Yeah, it would help with using the tool to access a private-to-the-remote API.

Won't immediately help with giving that tool access to the file system or Git.

For a local VM, you can have file system mounts, fast enough for Git.

SSHFS could help in some genuinely distant remotes with access to the file system (though SSHFS in the context of multiple file writers is fraught with risk of file corruption; been there, bought that T-shirt).

With properly network-remote VMs, nothing helps that much with giving the tool access to performing Git operations on changes inside your remote: Git is slow over network file systems even when they are quite local.

This is the real power of the VS Code remote after all; everything happens there.