[CWuestefeld]

I suspect that you're relying too heavily on the user here. Even for myself, a very experienced developer, I don't have a flash of insight over what my risk exposure might be for what I'm opening at this moment. 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". Expecting us to surface from our flow, think about the risks and make an informed decision might on the surface seem like a fair expectation, but in the real world, I don't think it's going to happen.

Your recommendation makes sense as a strategy to follow ahead of time, before you're in that flow state. But now you're relying on people to have known about the question beforehand, and have this strategy worked out ahead of time.

If you're going to rely on this so heavily, maybe you should make that strategy more official, and surface it to users ahead of time - maybe in some kind of security configuration wizard or something. Relying on them to interrupt flow and work it out is asking too much when it's a security question that doesn't have obvious implications.

[Tyriar]

> 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?

[CWuestefeld]

> Trusting this folder means code within it may be executed automatically.

But as you point out elsewhere, what constitutes code is very context dependent. And the user isn't necessarily going to be sufficiently expert on how Code interacts with the environment to evaluate that context.

> I'm curious what would stop you from opening it in restricted mode?

Even after years of using Code, I don't know the precise definition of "restricted mode". Maybe I ought to, but learning that isn't at the top of my list of priorities.

> 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?

NO! Not even close! And maybe this is at the heart of why we're not understanding each other.

My goal is not to run an editor and change some characters, not at all. It's so far down the stack that I'm scarcely aware of it at all, consciously. My goal is to, e.g., find and fix the bug that the Product Manager is threatening to kill me over. In order to do that I'm opening log files in weird locations (because they were set up by some junior teammate or something), and then opening some code I've never seen before because it's legacy stuff 5 years old that nobody has looked at since; I don't even have a full picture of all languages and technologies that might be in use in this folder. But I do know for sure that I need to be able to make what edits may turn out to be necessary half an hour from now once I've skimmed over the contents of this file and its siblings, so I can't predict for sure whether whatever the heck "restricted mode" will do to me will interfere with those edits.

I'm pretty sure that the above paragraph represents exactly what's going on in the user's mind for a typical usage of Code.

[nacs]

Thanks for being part of the discussion. Almost every response from you in this thread however comes off an unyielding, "we decided this and it's 100% right"?

In light of this vulnerability, the team may want to revisit some of these assumptions made.

I guarantee the majority of people see a giant modal covering what they're trying to do and just do whatever gets rid of it - ie: the titlebar that says 'Trust this workspace?' and hit the big blue "Yes" button to quickly just get to work.

With AI and agents, there are now a lot of non-dev "casual" users using VS code because they saw something on a Youtube video too that have no clue what dangers they could face just by opening a new project.

Almost noone is going to read some general warning about how it "may" execute code. At the very least, scan the project folder and mention what will be executed (if it contains anything).

[oenton]

For what it's worth, I absolutely agree with the comments saying the warning doesn't clearly communicate the risks. I too had no idea opening a directory in VS Code (that contains a tasks.json file) could cause some code to execute. I understood the risk of extensions but I think that's different, right? i.e. opening a trusted project doesn't automatically install extensions when there's an extensions.json (don't quote me on that, unless that's correct)

To give some perspective: VS Code isn't my primary IDE, it's more like my browsing IDE. I use it to skim a repo or make minor edits, without waiting for IntelliJ to index the world and initialize an obscene number of plugins I apparently have installed by default. Think—fixing a broken build. If I'm only tweaking or reinstalling dependencies because the package-lock file got corrupted and that's totally not something that happened this week, I don't need all the bells and whistles. Actually I want less because restarting the TypeScript service multiple times is painful, even on a high end Mac.

Anyway enough about IntelliJ. This post has some good discussions and I sincerely hope that you (well, and Microsoft) take this feedback seriously and do something about it. I imagine that's hard, as opposed to say <improving some metric collected by telemetry and fed into a dashboard somewhere>, but this is what matters. Remember what Steve Ballmer said about UAC? I don't know if he said anything, but if it didn't work then it's not going to work now.

[Aurornis]

> 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?

Have you tried it? It breaks a lot of things that I would not have expected from the dialog. It’s basically regressing to a slightly more advanced notepad.exe with better grepping facilities in some combinations of syntax and plugins.

[weaksauce]

> 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?

loss of syntax highlighting and to a lesser extent the neovim plugin. maybe having some kind of more granular permission system or a whitelist is the answer here.

opening a folder in vscode shouldn't be dangerous.

[cookiengineer]

The funny part is that everyone expects you to make an informed decision about your security, without even providing any data to make that decision.

A better strategy would be:

- (seccomp) sandbox by default

- dry run, observe accessed files and remember them

- display dialog, saying: hey this plugin accesses your profile folder with the passwords.kdbx in it? You wanna allow it?

In an optimum world this would be provided by the operating system, which should have a better trust model for executing programs that are essentially from untrustable sources. The days where you exactly know what kind of programs are stored in your folders are long gone, but for whatever reason no operating system has adapted to that.

And before anyone says the tech isn't there yet: It is, actually, it's called eBPF and XDP.

[pseudohadamard]

You also get problems with overwarning causing warning fatigue. Home Assistant uses VS Code as its editor (or at least the thing you use to replace the built-in equivalent of Windows Notepad) and every single time I want to edit a YAML config file I first have to swat away two or three warnings about how dangerous it is to edit the file that I created that's stored on the local filesystem. So my automatic reaction to the warnings is "Go away [click] Go away [click] Go away [click], fecking Microsoft".

[edf13]

I’d like more granular controls - sometimes I don’t want to trust the entire project but I do want to trust my elements of it

[socalgal2]

How is this any different than anything else devs do? Devs use `curl some-url | sh`. Devs download python packages, rust crates, ruby gems, npm packages, all of them run code.

At some point the dev has to take responsibility.

[CWuestefeld]

Devs download python packages, rust crates, ruby gems, npm packages, all of them run code.

You allow developers to download and run arbitrary packages? Where I came from, that went out years ago. We keep "shrinkwrap" servers providing blessed versions of libraries. To test new versions, and to evaluate new packages, there's a highly-locked-down lab environment.

[jlarocco]

[flagged]

[dang]

Please don't cross into personal attack, regardless of how wrong someone is or you feel they are.

https://news.ycombinator.com/newsguidelines.html

[throw10920]

Yes. If you "can't" read the security popup that very clearly tells you that this is a risky action and you should only do it if you trust the repo, then it's either a reading comprehension issue, and you should take remedial classes - or you're intentionally ignoring it, and so deeply antisocial and averse to working with other people.

Both of those things are extremely bad in any work environment and I would never hire someone displaying either of those traits.