[spacemanspiff01]

The security risk comes from all those unvetted plugins, that have unrestricted access to the editor.

[shipp02]

That's an issue with any plugin system, right? AFAIK no IDE has a plugin system with capabilities or a sandboxed interpreter.

VSCode does have a thing where it's like do you trust the authors of this project. Not sure what it does because I've never had to use it. From StackOverflow[1]:

>If you select No, I don't trust the authors, Visual Studio Code will open the workspace in 'restricted mode'. This is the default for all new workspaces. It lets you safely browse through code but disables some editor feature, including debugging, tasks, and many extensions. However, keep in mind that 'restricted mode' is all you need for many use cases.

Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs.

[1]:https://stackoverflow.com/a/67914669/11422647 [2]:https://code.visualstudio.com/docs/editor/workspaces/workspa...

[vlovich123]

> Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs.

Unfortunately, it’s not. Restricted mode is VSCode without any plugins. That means that unless you’re doing very basic TS development (I think that’s the only language VSCode supports out of the box), then you’re kinda hosed.

[retsl]

There's a feature request from 2018 to add a proper permission model for plugins in VSCode: https://github.com/microsoft/vscode/issues/52116

Sadly it doesn't seem to make any progress.

[aniviacat]

Lapce uses a WASI plugin system, so it could do strong sandboxing (but it doesn't).

[causal]

Note that your local plugins do not get installed on remote instances without manually doing so

[rednafi]

Yeah, I'm all in for a more secure option as long as it allows me to do everything that VSCode's SSH agent does. But if the devex goes down the drain because of "security" then I'm good for now.