Next steps:

1. Look into any existing VS Code authentication code and see if it is anything like what we need or if we can tweak it to make it work for us.
2. If that is a bust then put up a proposal for the required API changes.

I should also mention that I think the first will only work once we fully convert to the fork. Right now we do not even spawn VS Code until we need it so we cannot rely on it for authentication. So we may need to punt on actual execution until that work is completed.

Right now we do not even spawn VS Code until we need it so we cannot rely on it for authentication. So we may need to punt on actual execution until that work is completed.

Ahh good point. Okay we'll reconsider this once we convert to the fork.

A problem I see with using vscode extensions for auth, is that extensions are activated on each user connection, and only after the main workbench is already working and a websocket connection has already been established. At this point it's way too late to block unauthorized users, as vscode is already usable while extensions are loading. An unauthorized user could have already opened a terminal before the extension is ready. If the user is not authorized, you'd then have to forcefully close the active websocket.

A separate auth system would be a lot simpler. vscode extensions are designed to be controlled by the main workbench (it's the workbench that decides if an extension should even run, and when), while you'd want authentication to be the one in control of the rest of the system.

That is a really, really good point!

Looks like we will need to preserve code-server's own plugin system and implement auth that way. Or we could scrap the plugin system and only support authentication modules.