Here's the initial exploration of what profiles could look like, starting with a basic example of setting up a "Demos" profile. In this profile, the user can choose to either start with an empty profile (no settings/extensions) or keep their existing data.

Concept A

This concept shows the entry point from the gear menu, but it could also be enabled via the command palette. I didn't show what extension management looks like (yet) because it requires a bit more thinking.

Concept B

This concepts attempts to re-use the accounts menu in the activity bar and also creates a default profile and reduces the effort involved with creating/switching accounts.

One idea for settings is to introduce a new settings object like:

{
    "profiles": {
        "demos": {
            "files.autoSave": "onFocusChange",
            "editor.fontSize": 18,
            "editor.tabSize": 2,
            "editor.fontWeight": "600",
            "screencastMode.enabled": true,
        }
    },
    
    "editor.fontFamily": "Cascadia Code",
    "editor.renderWhitespace": "all",
}

The "Demos" profile inherits the current settings a user has and adds additional settings on top of the current ones. Also, when profiles are enabled we will create a "Default" profile where the user can switch back to their default mode.

So with this approach if I update a setting in the default profile (say editor.fontFamily) but I want the Demos profile to use the default font instead, it should be overridden with its default value here?

That would also mean that every change made in the default profile is automatically inherited by all other profiles? If the change was intended only for the default profile, all other profiles should be modified to revert that change?

I realize it is probably unlikely someone will have a high number of profiles (but who knows, really?); one way to avoid the revert problem above would be to not inherit from the default profile, maybe only use it as a starting point when a new profile is first created. Of course that also means if I change a setting in the default profile that I do want inherited, I'm out of luck... Maybe this inherit from default profile could be a setting as well?

Maybe this inherit from default profile could be a setting as well

What if it was set up in a similar way to how .eslintrc can "extend" other configurations?

For example, when you create a new profile it starts with an "extends-profile": "default" setting which would mean it always inherits from the default, even if default changes. If you no longer want this behavior just remove this extends setting and this profile would go back to App defaults for everything that's not set for that profile?

This would also allow profiles to extend each other (and maybe even allow people to share them!). To go with OPs example, maybe I have a teaching profile with bigger font/zoom and some parts hidden. But now I start teaching another class in a different language and I want a different set of extensions or maybe a different theme that's better for this language. I could just create a new profile that extends my base teaching profile with just the new settings.

I guess this would still leave the question of "if I change a setting of the 'child' profile, which level of the config do I want it on, this one or the parent?" Maybe it's still best to have no inheritance at all and all new profiles should start with App defaults or duplicate the default at creation.

Also not directly related to current conversation but the term "Profiles" threw me off at first. I was expecting something along the lines of User profiles like multiple Chrome accounts. Not different configuration sets. I think profiles works but it may be worth thinking of alternatives?

Yea I did originally play around with the "inheritance" concept, mostly focused on disabling it in a certain profile. The idea of mixing profile sounds interesting but would love to see a use case for it first because it could add some unnecessary complications, like you just described.

In terms of the term "Profiles", this one is tricky because we do also have user accounts where you login for certain extensions (like GitHub or Azure), so we want to make sure those are separated and not mixed. But thanks for this feedback, we'll gauge to see if we get similar feedback.

I prefer concept B. Looking together with #115641, maybe there is no such strong need for the account manager. I personally never touched it after setting up all my accounts.

However, from these early concepts, I did get how it will resolve all related issues.

• Can I use different profiles for different Code instance? Will it switch profile automatically when opening a workspace or enter/exit screencast mode?
• I care more about [Feature] Local Workspace settings #40233, what's the priority of profile settings? Will it be like user settings < profile user settings < workspace settings < workspace profile settings?

Another related issue is #95182, which proposes the term "perspectives".

Here's the initial exploration of what profiles could look like, starting with a basic example of setting up a "Demos" profile. In this profile, the user can choose to either start with an empty profile (no settings/extensions) or keep their existing data.

Concept A

This concept shows the entry point from the gear menu, but it could also be enabled via the command palette. I didn't show what extension management looks like (yet) because it requires a bit more thinking.

This looks very good and easy to use also.
B is hard to navigate in my opinion.

Hi, would this "user profile" concept work for multiple accounts in vscode itself? For example, I use vscode for personal projects (personal email & GitHub account, this one), but also for work (my employer's msft-based email & work GitHub account), potentially also integrating with a customer's system (e.g. their Microsoft account). However, I want my settings to sync via my personal email (for example), or at least to start both from the same config.

Great ideas! I'm looking for a simple tool that allows me to switch profiles/extensions between my HTML/CSS/JS stack, my Python stack, and my Ruby stack. There's no need for one set of extensions to coexist with the other sets of extensions, and it's really tedious to enable/disable extensions by hand.

For example, when coding Ruby, I don't need ESLint to be enabled as an extension. I would prefer it ESLint just "didn't exist" in that VS Code workspace (not merely be disabled).

There is already an extension that does much of this, Profile Switcher. Unfortunately, it's still in version 0.3.3 and has been since 2019. It appears to be abandonware. It might be buggy, or I might be buggy (PEBMAC), but it seems to have "forgotten" a large number of my favorite extensions. Now I need to do a "hard reset" of VS Code and reinstall them.

https://www.aaron-powell.com/posts/2019-06-28-vscode-extension-for-managing-profiles/

There are articles/blog posts at the links below about how to switch user profiles from the command line. However, this also seems rather tedious.
https://dev.to/sulmanweb/vs-code-pro-tip-code-profiles-multi-environment-development-hg2
https://www.reddit.com/r/vscode/comments/c2h4a7/different_profiles/
https://dev.to/jsjoeio/how-to-create-code-profiles-in-vscode-3ofo
https://www.freecodecamp.org/news/how-to-create-code-profiles-in-vscode/

Could the VS Code team please consider making this an available option? It could be as simple as taking the existing Profile Switcher code (MIT licensed) and cleaning it up.

There's also another extension, "User Profiles," that seems to have been released just a few days ago.
https://github.com/cyberbiont/vscode-profiles

Is inheritance of the profiles still planned?

I tried out settings profiles and created some, but they seem not to follow changes in my default profile.

This kinda makes it a bit useless for me, because I do like to for example enable experimental features some times, or change the font etc. and it would be a shame if I have to do this for each and every profile separately.

@LasseRosenow inheriting from default profile is tracked here - #156144. It would be great if you can provide your usecase in that issue.

How ExtensionContext.globalStorageUri work with profiles? We use vscode.Uri.joinPath(context.globalStorageUri, "../../snippets") to get user snippets, and find globalStorageUri will not change with profiles. zjffun/vscode-snippets-manager#8

VS Code uses userDataProfileService.currentProfile.snippetsHome internally, could snippetsHome provide to extensions?

Thank you.

ExtensionContext.globalStorageUri always points to same location irrespective of profiles. Please follow up in this issue - #160466

I read the issues. The ideas are very interesting, but I hope they are not limited to modifying the global setting file manually, but like Windows, Only simple operations are needed. For example, extension sets can be moved like files. Extensions can be placed in different extension sets. At the same time, simple operations can be used to set what extension sets and setting files the environment needs. The whole process does not need to display and modify the global setting file. At this point, the issue can be closed

Closing this plan item as this feature is Generally Available from next stable. Please file separate issues for any other requirements or bugs. Thanks every one of the feedback.

Closing this plan item as this feature is Generally Available from next stable. Please file separate issues for any other requirements or bugs. Thanks every one of the feedback.

I'm kinda new to VS Code Insiders. Is it already available in Insiders? Thank you for the great work.

关闭此计划项，因为此功能已从下一个稳定版正式发布。请针对任何其他要求或错误提交单独的问题。感谢每一个反馈。

Can you tell me what new content has been added to this problem

I'm kinda new to VS Code Insiders. Is it already available in Insiders? Thank you for the great work.

Yes, and will be available in next stable release too.

Thanks for Profiles. It is the best feature ever.

I've just started using it with eight profiles, including one "Airplane Mode" 😎

Where can I find the profiles documentation?

I've seen this update;
https://code.visualstudio.com/updates/v1_75#_profiles

But didn't find a link to the documentation.

@equiman WIP: microsoft/vscode-docs#6020

I was also surprised that they released a new feature without actually telling us how to use it.

Sorry about that, and we will be coming up with user guide soon. I thought that the summary in release notes - https://code.visualstudio.com/updates/v1_75#_profiles is good enough to start with. But I agree user guide is definitely needed.

@sandy081 No worries - the wait was well worth it, because user profiles is an awesome new feature!

@sandy081 Any command line to start a specific profile?

@sandy081 Any command line to start a specific profile?

Please use code --help to learn what arguments you can specify.

@sandy081 Any command line to start a specific profile?

Yes, you can use the --profile flag.

code --profile "Default"
code --profile "DotNet"
code --profile "React"
code --profile "Node"

I've also defined some aliases that help open the current path using some profiles.

alias vc="code --profile \"Default\""
alias vco="vc ."
alias vcn="vc . -n"
alias vd="code --profile \"DotNet\""
alias vdo="vd ."
alias vr="code --profile \"React\""
alias vro="vr ."
alias vn="code --profile \"Node\""
alias vno="vn ."