My main hesitation here was that really it's just a false sense of security though. Tasks is just one of the things this enables, and in the core codebase we are unable to determine what exactly it enables as extensions could do all sorts of things. At a certain point, it's really on the user to not dismiss the giant modal security warning that describes the core risk in the first sentence and say they trust things they don't actually trust.
I've also created these follow ups based on this thread:
Syntax highlighting should work if the highlighting is provided by a textmate grammar, it will not work if it's semantic highlighting provided by an extension and that extension requires workspace trust. If it's possible to highlight without executing code, that sounds like an extension issue for whatever language it is. I believe extensions are able to declare whether they should activate without workspace trust and also to query the workspace trust state at runtime.
Didn't mean to come off that way, I know a lot of the decisions that were made. One thing I've got from this is we should probably open `/tmp/`, `C:\`, ~/`, etc. in restricted mode without asking the user. But a lot of the solutions proposed like opening everything in restricted mode I highly doubt would ever happen as it would further confusion, be a big change to UX and so on.
With AI the warning needs to appear somewhere, the user would ignore it when opening the folder, or ignore the warning when engaging with agent mode.
AI certainly made everything in this area more complicated. I 100% agree about sandboxing and we have people investing in this right now, there's an early opt-in version we just landed recently in Insiders.
Some JIT notification to enable it and/or a status bar/banner was considered, but ultimately this was chosen to improve the user experience. Instead of opening a folder, having it restricted and editing code being broken until you click some item in the status bar, it's asked up front.
It was a long time ago this was added (maybe 5 years?), but I think the reasoning there was that since our code competency is editing code, opening it should make that work well. The expectation is that most users should trust almost all their windows, it's an edge case for most developers to open and browse unfamiliar codebases that could contain such attacks. It also affects not just code editing but things like workspace settings so the editor could work radically different when you trust it.
You make a good point about the cookie banner reflex, but you don't need to use accept all on those either.
It's intentionally prominent as you're in a potentially very degraded experience. You can just click the x to hide it which is remembered the next time you open the folder. Not having this banner be really obvious would lead to frustrated users who accidentally/unknowingly ended up in this state and silly bug reports wasting everyone's time about language services and the like not working.
> I don't have a flash of insight over what my risk exposure might be for what I'm opening at this moment
Maybe I'm too close to it, but the first sentence gives a very clear outline of the risk to me; Trusting this folder means code within it may be executed automatically.
> I don't have a comprehensive picture of all the implications, all I'm thinking is "I need to open this file and twiddle some text in it".
I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?
> Your recommendation makes sense as a strategy to follow ahead of time, before you're in that flow state.
You get the warning up front when you open a folder though, isn't this before you're in a flow state hacking away on the code?
"May" is the most correct word though, it's not guaranteed and VS Code (core) doesn't actually know if things will execute or not as a result of this due to extensions also depending on the feature. Running the "Manage Workspace Trust" command which is mentioned in the [docs being linked][0] to goes into more detail about what exactly is blocked, but we determined this is probably too much information and instead tried to distill it to simplify the decision. That single short sentence is essentially what workspace trust protects you from.
My hope has always been, but I know there are plenty of people that don't do this, is to think "huh, that sounds scary, maybe I should not trust it or understand more", not blinding say they trust.
It's not just the .vscode folder though, the Python extension for example executes code in order to provide language services. How could this threat detection possibly be complete? In this new LLM-assisted world a malicious repository could be as innocuous as a plain text prompt injection attack hidden in a markdown file, or some random command/script that seems like it could be legitimate. There are other mitigations in place and in progress to help with the LLM issue, but it's a hard problem.
As called out elsewhere, workspace trust is literally the protection here which is being circumvented. You're warned when you open a folder whether you trust the origin/authors with pretty strong wording. Sure you may find this annoying, but it's literally a security warning in a giant modal that forces you to chose.
Even if automatic tasks were disabled by default, you'd still be vulnerable if you trust the workspace. VS Code is an IDE and the core and extensions can execute code based on files within the folder in order to provide rich features like autocomplete, compilation, run tests, agentic coding, etc.
Before workspace trust existed, we started noticing many extensions and core features having their own version of workspace trust warnings popping up. Workspace trust unified this into a single in your face experience. It's perfectly fine to not trust the folder, you'll just enter restricted mode that will protect you and certain things will be degraded like language servers may not run, you don't be able to debug (executes code in vscode/launch.json), etc.
Ultimately we're shipping developer tool that can do powerful things like automating project compilation or dependency install when you open a folder. This attack vector capitalizes on neglectful developers that ignore a scary looking security warning. It certainly happens in practice, but workspace trust is pretty critical to the trust model of VS Code and is also an important part to improve the UX around it as we annoy you a _single_ time when you open the folder, not several times from various components using a JIT notification approach. I recall many discussions happening around the exact wording of the warning, it's a difficult to communicate concept in the small amount of words that it needs to use.
My recommendation is to use the check box to trust the parent or configure trusted folders. I personally have all my safe git clones in a dev/ folder which I configured to trust, but I also have a playground/ folder where I put random projects that I don't know much about and decide at the time I open something.
> So, Lord have mercy on my soul if I have a new hire tell me "I don't know how to use the regular terminals. All I can use is VSCode's terminal." I think sometimes things should be hard, but I don't think terminal autocomplete is very hard. Just hit tab a few times and it'll do its thing or -h.
Thanks for the insights. Something I've learned here is that the vast majority of users don't change their defaults or seek out features they may find very useful. Discoverability vs simplicity/bloat is a hard problem and that's essentially the issue here.
I made a note on the issue that with the planned changes to make it easier to configure, we should consider not overriding tab by default anymore. That would mean that only down arrow is bound by default which would then put focus into the widget.
> I'm going to have to look through my settings to try and turn that all off.
Full details at https://code.visualstudio.com/docs/configure/telemetry, but setting `"telemetry.telemetryLevel": "off"` will disable usage/crash/error telemetry for the VS Code core. Just keep in mind extensions may or may not respect that.
One of the things we should definitely action is hiding it in more places where it doesn't work well, that's one of the key pieces of feedback we got and is tracked in https://github.com/microsoft/vscode/issues/282578
Hi from the VS Code team - I recently went into detail about why we did this in https://github.com/microsoft/vscode/issues/282268#issuecomme.... We believe it'll be beneficial overall and go a long way in lowering the bar to make the terminal less intimidating for newcomers. Conflicts with muscle memory was always a big concern which is why we made extra effort to be able to turn it off, the comment below that one outlines some steps we're making to make it more easily configurable inline.
On the roll out side, this is what we observed:
- It was enabled in Insiders for several months, generally only very positive reactions
- It was surprising to me that we shipped this to 25% of our stable users and basically no one complained for 2 weeks before we rolled out to 100%
- After hitting 100% of users we did see some backlash like this comment
- Of course telemetry doesn't show the whole story, but we try to determine both whether the completion was modified and whether the command was successful after using it and both numbers stayed relatively stable since shipping in Insiders at what we consider pretty good numbers (both accept without editing and command success rate is ~80%).
You could look up activation events on the website, I don't think we guarantee anything relating to order other than that. Generally the order in which they're activated shouldn't matter in practice.
VS Code team member here. The diagram in the article is a little wrong, but the basics of it are:
- The "main process" which manages the windows (renderer processes)
- The renderer process" contains the UI thread for each window, the renderer process can have its own worker threads
- The extension host loads extensions in proc, extensions are free to create their own threads/processes. The separate process for extensions protects extensions from freezing the renderer
- Various other processes that live off either the main process or the "shared process", such as the pty host for terminals which enables the terminal reconnection feature when reloading a window (also file watcher, search process)
We've been shuffling where processes are launched from recently but the actual processes and their purpose probably won't change. You can view a process tree via Help > Open Process Explorer to help understand this better.
My main hesitation here was that really it's just a false sense of security though. Tasks is just one of the things this enables, and in the core codebase we are unable to determine what exactly it enables as extensions could do all sorts of things. At a certain point, it's really on the user to not dismiss the giant modal security warning that describes the core risk in the first sentence and say they trust things they don't actually trust.
I've also created these follow ups based on this thread:
- Revise workspace trust wording "Browse" https://github.com/microsoft/vscode/issues/289898 - Don't ask to enable workspace trust in system folders and temp directories https://github.com/microsoft/vscode/issues/289899