Tyriar

We're planning on switching the default in 1.109 with https://github.com/microsoft/vscode/issues/287073

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

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.

Good point about one off edits and logs, thanks for all the insights. I'll pass these discussions on to the feature owner!

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.

[0]: https://code.visualstudio.com/docs/editing/workspaces/worksp...

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.

VS Code team member here :wave:

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.

Various settings are `restricted` in the codebase to only use them when the workspace is trusted. `allowAutomaticTasks` is one such setting: https://github.com/microsoft/vscode/blob/f7730c409e14af94d75...

So a malicious repo can easily override it... if you say you trust it.

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

Here's that specific event if you're interested: https://github.com/microsoft/vscode/blob/b0e9dce905d12646801...

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

For that WSL one specifically we'll get it fixed in https://github.com/microsoft/vscode/issues/285037

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%).

It's actually been the default since v1.55 which released early April 2021: https://code.visualstudio.com/updates/v1_55#_webgl-renderer-...

Before that from v1.17 (~October 2017) it was using a 2d canvas context: https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...

I think it was always a Google product https://github.com/GoogleChrome/lighthouse/tree/9ff34c320811.... If I remember right it was an evolution of the page speed test site (can't remember exact name) of which Google was also a contributor to.

There's plenty that can be said about Google, but investing in education and testing around web performance was one of their stand out achievements imo.

I work on VS Code. We have a feature for this exact problem that enforces a minimum contrast ratio of 4.5:1 via shifting the luminance of the foreground text by default https://code.visualstudio.com/docs/terminal/appearance#_mini... . This feature's in xterm.js so any terminal based on xterm.js can leverage this.

We actually got a bit of push back when this was released but I haven't heard anything for quite a while now that some time has passed and we have a FAQ for colors not being "correct".

I'm on the VS Code team and maintain xterm.js.

Smooth scrolling in VS Code is primarily about animating scroll events such that scrolling with a mouse wheel doesn't just scroll an increment immediately but over a fixed time, updating at a high refresh rate. This is supported in both the editor and the terminal.

The other part of smooth scroll is being able to render lines offset on the y-axis which is supported by Monaco (the editor part), but not xterm.js (the terminal part). I can't actually seem to find the issue for this, but I've been wanting to implement it for a while. It's quite simple to offset the text, the slightly harder part is to render an additional row so you can see a partially rendered line on the top/bottom.

I'm on the VS Code team and maintain xterm.js which is what Hyper's frontend is based on. There are actually multiple developments happening in this area.

First, there's a contribution from the author of DomTerm which adds grapheme cluster support to xterm.js, which will correctly merge and size things like emoji that are called out in the post. This is currently based on Unicode 15. See https://github.com/xtermjs/xterm.js/pull/4519

Second, while Windows Terminal does seem to work with emoji sometimes, it doesn't all the time. I'm not 100% sure, but I think it may only work on Windows ptys, not in WSL for example. Last time I spoke with the team they said they're working on a rewrite which could lead to proper emoji support.

Sounds like they meant its good news if you're not a mosquito magnet?

You can press f8 to view the problem in a "peek view" under the problem line, or view on the problems panel.

For many games, idle games are a special case though, I don't think anyone who plays an idle game would want the logic loop to pause. They typically take a long time to play so minimizing and checking back every now and then is a very common thing.

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.

EDIT: Formatting

Const enums specifically are great, since they disappear on compile you can use them to internally document strings/numbers with verbose names/comments without the cost of a const variable that would appear after compilation.

As for the fact that types cannot simply be stripped out, I've found building using plain tsc and have the bundler target tsc's output directory. This separation is needed since most tools don't support TypeScript project references anyway which I find extremely useful for organizing internal modules.

MS acquired that extension, Don works at MS now.

MS dev here. Thanks for calling this out. I contacted the GH@MS admins to look into this and to consider adding some safeguards to the tooling so this doesn't happen in the future.

MS dev here. I contacted the internal repo owners to bring this to their attention, people may be out for the holidays but I expect it to get fixed up soon.

I used to care a lot more about code style, now when I get those feelings while reviewing I'll instead invest that effort into setting up a lint rule so it's the last time I need to make the comment.