Insiders - Extension descriptions and settings windows open in a separate modal window

[slushhh]

Does this issue occur when all extensions are disabled?: Yes/No

• VS Code Version: Visual Studio Code - Insiders, 1.110.0-insider
• Insiders build date: 2026-02-20
• OS Version: macOS Tahoe 26.3

With some Insider version (I haven't tracked down which one), when navigating through extension descriptions, the descriptions open in a separate modal window, whereas previously they opened as a standard tab.

The editor settings are the same: pressing Cmd + , opens the settings in a separate modal window. All open extension settings/descriptions can, of course, be moved to tabs, but to do so, you have to click the Open Modal Editor in Main Window button each time.

Project files, however, open in tabs, as expected.

[gjsjohnmurray]

"workbench.editor.allowOpenInModalEditor": false will turn off this new feature (Modal Editors) entirely. Other settings control it selectively.

[slushhh]

"workbench.editor.allowOpenInModalEditor": false will turn off this new feature (Modal Editors) entirely. Other settings control it selectively.

Hi John! Thanks for the tip about the settings. I saw they're experimental.
But I think they should be disabled by default, as they change the familiar workflow and default editor behavior.

[gjsjohnmurray]

pinging @bpasero

[bpasero]

But I think they should be disabled by default, as they change the familiar workflow and default editor behavior.

The use of modal editors is experimental as we gather feedback. There are 2 independent settings for controlling this for settings/keybindings editor and extensions.

Can you elaborate how the new experience is worse for you compared to the non-modal experience?

[slushhh]

@bpasero Hi Benjamin!

Can you elaborate how the new experience is worse for you compared to the non-modal experience?

Of course, so:

1. This isn't the editor's usual behavior. Users have long been accustomed to extension navigation and the settings window opening as tabs. Now the editor's behavior will change. The first reaction is "Why? Did something break?" This will force users to either create an issue on GitHub, or spend time reading the release documentation to understand what was changed, or delve into the editor's numerous settings. This is all a waste of time that can be avoided.

2. Extension navigation: the first time you click on any extension, its description opens in a tab. Then you scroll through the list of extensions as much as you like, clicking on the ones you need, seeing what they are, what they say, and so on. The open tab is reused each time; it's a very fast process.

This won't work with a modal window; the new experience significantly slows down the process. An open window interferes with navigation; the user must first close it to scroll through the list of extensions and move on to the next one they need.

The modal window has a navigation block at the top that allows you to navigate to the previous/next extension, but this block is useless if you need to see the list of extensions and quickly scroll through it, skipping over a ton of unnecessary extensions. Overall, the modal window slows things down significantly.

3. Settings in a modal window. I also don't see any point. I work on a MacBook, so the display isn't very large to begin with, and the editor is always maximized. Opening content in a small modal window makes the content area even smaller. So, to comfortably navigate the settings list, I need to move the modal window to a tab.

4. This point is more about the fact that the purpose of moving such features to a modal window isn't entirely clear, i.e., what they're supposed to add to the UX.

In my opinion, this should be disabled by default. Hope this information is useful😊

Cheers🎉

[bpasero]

The experience for extensions is work in progress, one idea is to move the extensions sidebar into the modal as well so that the experience of navigating extensions does not degrade. I do not expect us to ship this by default in Code stable before that happens. You can turn it off via extensions.allowOpenInModalEditor setting.

For other editors, I find the choice of modal easier to justify, and this impacts: Settings, Keybindings, Workspace Trust, Profiles, AI models & AI customisation. I see these as experiences where I jump in, make a choice and then jump out. I do not feel that these editors belong into the same window where my text editors are where I do software engineering. Opening these editors as tabs, I am forced to clean them up again when I am done and I might be forced to make room for the editor to show fully if my layout is a grid layout where not all editors are showing maximised, so your argument that your editor is always maximised might not be true for other people in other layouts.
As for the size of the modal: I hear you and feel the same, I just pushed a change to increase their default size to 1400x900. On top of that there is an action to maximise modal editors, I can see that this might warrant a setting too, to just always maximise.

Screen.Recording.2026-02-23.at.17.39.14.mov

In other words: I encourage you to play around more with the modal editors for everything but extensions, where the experience is not final yet. That can be controlled via extensions.allowOpenInModalEditor setting.

[bpasero]

Closing for now as we do not ship this on by default for now.

[henk9]

"workbench.editor.allowOpenInModalEditor": false

The workbench.editor.allowOpenInModalEditor setting doesn't have any effect at all.
https://imgur.com/1Y3Embr
I guess my only option is to switch back to an older version of VSCode?

[gjsjohnmurray]

@henk9 maybe try the workbench.editor.useModal setting.