VS Code and consent

in my free time i help administer an art squat living on a shared Linux server. we heavily vet applications so most everyone we let in is acting in good faith, and for that reason our resource usage limits are high and relaxed.

mistakes happen, of course. sometimes our server will run a bit slow if someone is running a leaky process. but the chat will notice, let us know, and maybe even get in touch with the owner of that process to see if they can kill it. this model has been sustainable for as long as i've been in this community, and crashes are few and far between.

or at least they used to be. in the past couple of months, we've had our server grind to a halt seven times. seven times where we've had to pull the plug, reboot the server, and tell everyone to get their tmux sessions built back up. again. seven times where everyone slowly joins the irc just a bit after we explained what happened, making the chat an irritating nuisance until everyone is brought up to speed.

i'll save you the weeks of research and confusion — it's VS Code. more specifically, VS Code's remote SSH functionality, which spins up a headless process on the server and connects the desktop computer to it. the obvious solution would be to delete VS Code from our server, but the thing is we've never had it installed. this thing shells in, installs itself in a user's home directory, then spins up a process — impossible to track down neatly.

after countless, countless, countless attempts to get it to stop naturally, we dusted off the nuclear method, and have resorted to pkilling vscode-server every minute. we eventually had to add windsurf-server. then i rewrote the whole thing to keep logs and send emails, so we could directly tell people to turn that mode of VS Code off and serve the filesystem over SFTP like normal.

as it turns out, this is VS Code's only supported mode for remote development. they don't have the equivalent of Emacs' TRAMP, at least not via official plugins. VS Code operates under the implication that whatever machine you shell into is owned by you, and that spinning up a resource-intensive editor process on that machine without explicitly telling you is fine. all the user sees is some files.

to make matters worse, this process doesn't listen to SIGTERM. that cron job i wrote was eventually amended to use SIGKILL(!) but VS Code's solution to loss of connection is to immediately restart the process. this program was never built with the thought that it might be killed for good reason. surely we should give its royal highness nice -20 and kill every other process so it can roam free.

i know that if i went and complained on the VS Code issue tab, i'd be told to put some limits in place. and, sure, that would fix the issue, but that's not the point. the point is that this is functionality that hides its true operation from the user, ignores being told off, doesn't transparently relay these errors, and doesn't have a way to turn itself off.

oh, and it leaks resources. this would be fine if it didn't, i guess, but it leaks like crazy. one time it wrote its extensions to a directory it couldn't read from, and filled up two thirds of the disk before being killed. fuck Microsoft.