Add untrustedWorkspaces: { supported: true } capability and limit all configuration properties to the application scope (so that workspaces can't override our settings, which is not really useful anyway IMO), or
Add untrustedWorkspaces: { supported: 'limited' } capability and restrict all configuration just to trusted workspaces.
The reason we need to disable reading settings from the (untrusted) workspaces is e. g. a malicious actor can override activitusbar.views with something along the lines of
Just noticed the activitusbar.combineWorkspaceSettings, so perhaps the second approach would work better. I'm really curious about the use cases for this, though :-)
Right now Codium 1.59.1 (I'll test on official VS Code build a bit later) blocks the extension if running in Restricted Mode:
As I see from studying the Workspace Trust Extension Guide, there's two ways to mitigate that:
untrustedWorkspaces: { supported: true }
capability and limit all configuration properties to theapplication
scope (so that workspaces can't override our settings, which is not really useful anyway IMO), oruntrustedWorkspaces: { supported: 'limited' }
capability and restrict all configuration just to trusted workspaces.The reason we need to disable reading settings from the (untrusted) workspaces is e. g. a malicious actor can override
activitusbar.views
with something along the lines ofWhat do you think?