My comment had more to do with the in-browser VS Code instance. Regardless of the extension security model, having the github.dev webapp run under your full github.com account's permissions significantly expands the attack surface: if you launch github.dev in one repo and install a malicious extension, that extension can reach and compromise all repos your GitHub user can reach, private or public. Scoping it to one repo would only allow a malicious extension to write code in that repo and not mess with the GitHub API or other repos.

Separately, I think the debate around extensions/plugins in general boils down to the same conversation about trust and isolation we have for every third-party software supplier (package managers etc.).

Options include:

1. Vetting/blessing certain extensions.

2. Serving built extensions from a central registry/artifact store with security protections

3. Having VSCode organically grow a shitty version of different operating systems' "X wants to access Y; confirm?" permissions access system (a pain in the ass to do in a cross-platform way).

4. Having VSCode somehow run extensions as separate applications according to the OS and leveraging the OS's permission system (still hard, and because it's an IDE, rather a lot of extensions will need--or request because of sloppy extension code--very broad permissions, at which point an extension is one transitive dependency update away from compromising your system).

5. Running the entire VSCode instance in some sort of container/VM/sandbox (the amount of access holes folks poke in the Snap/Flatpak VSCode instances, and the number of common issues for which "stop using the container and install VSCode directly on the system" is the recommended fix does not give me hope that this will be adopted by anyone but the most expert, patient, and paranoid users).