Ability to create different profiles.

[eznix86]

Check for existing issues

• Completed

Describe the feature

Currently we have only 1 default setting. The problem arises for people working on different projects which needs different settings.

Example; We can have Rust Profile (which has all the settings for the best experience for Rust). Laravel Profile, Django Profile. Python profile etc. It doesn't need to be specific. But we just need to have the ability to have different profiles.

If applicable, add mockups / screenshots to help present your vision of the feature

We can have prebuilt profiles (for specific languages/frameworks) or we can have custom profiles. Those profiles can be exported, imported, deleted, extended.

[jansol]

IIRC there are already some per-language settings, but there definitely is more that could be done with that.

[JosephTLyons]

We also have local settings as well - which can kind of act as a bandaid in this case, though, it isn't ideal in the context of the original request.

[ceopaludetto]

Personally, I think this should follow something like tsconfig.json does. So I want to introduce two new concepts:

1. The extends: string | string[] + name: string options, this will allow us to do:

{
  // The base profile
  "name": "base",

  "theme": "Catppuccin Mocha",
  "vim_mode": true,
}

And then:

{
  // The typescript profile
  "extends": ["base", ...],
  "name": "typescript",

  "languages": {
    "TypeScript": {
      "code_actions_on_format": {
        "source.fixAll.eslint": true
      }
    }
  }
}

Primitive options like string | number | boolean should be overwritten and object | array should be merged together

2. The extensions: string[] (or maybe extensions: { include: string[], exclude: string[] }) option. We need to disable/enable some extensions in different profiles. Nowadays VSCode allow us to disable in UI, but personally, I prefer to disable via settings.json

{
  // The base profile
  "name": "base",

  "theme": "Catppuccin Mocha",
  "vim_mode": true,
}

{
  // The swift profile
  "extends": ["base", ...],
  "name": "swift",
  
  "extensions": ["zed:sourcekit-lsp-extension"]
}

Some people also like the ability to disable all extensions in the base profile and only enable on specific ones, I think all this possibilities should be supported.

What you think?

[jansol]

Hmm... Should the profile also specify the github account and e.g. git author info to use (once we have git commit support)? I.e. separate "work" and "personal" profiles.

Formatting etc options should really be done via local settings IMHO, since different repos have different policies for that.

[shishkin]

Local settings work really well for a lot of use cases. However, since local settings are (usually) checked into source control, they are bad for personalization settings. E.g. setting fonts/themes for the whole team is not a good idea. Profiles can solve for that.

But the most need for profiles (as implemented in VS Code) I have is to selectively load extensions based on programming language. While performance concern might not (yet) be an issue for zed, but some extensions can start conflicting with other ones. Again, putting this in local settings may solve part of the problem, but I would hesitate to force all my non-essential extensions on the whole team.

[olejorgenb]

However, since local settings are (usually) checked into source control,

This is why there should always be multiple setting layers IMO. For tools which does not support this I think it's better to provide a template settings file which the developers can choose to merge manually with their own settings file. (or just symlink if they want to use the default)

[eznix86]

Hey, thanks for keeping this issue up.

Some feedback on my side:

I believe a profile is per project. we can have a .zed folder which takes the users configuration and merge it with the settings.json living inside of the .zed folder.

This allow teams to share extensions for example. I believe the .zed folder should allow a subset of the configuration, which means, you cannot change theme in a .zed folder.

Basically I believe for sanity, the word "Extending" is just a cloning of the json which technically another profile being duplicated.

So we can have settings.json, and even nvim.json, python.json or more.

[shishkin]

I believe a profile is per project.

That's something I strongly disagree. Profile is a user-specific and idiosyncratic set of extensions and preferences that are often used together. E.g. while working on devops automation I may prefer different layout from that when I work on mobile or web apps. And those preferences are not something I would impose on a team working on the same project. In addition, I would like to easily reuse such profiles for many projects, so initial project setup doesn't involve copying and tweaking zed config from a previous project. Again, project settings are shared, while profiles should be private.

[eznix86]

@shishkin I agree, but I wasn't explicit enough, what i meant was a profile can be reused by a project.

Example; you have 10 projects, you have 3 profile. But you open the 9th project in profile number 2, it should reopen with the same profile each time, unless you change it.

But we can have a profile per project. Example;

Let's say you have your current profile activated, since it has a .zed with settings.json inside it will merge your config with what we have in the .zed folder.

So it is user specific at its core, but if you open different projects on different profile, we should be able to memorize that this project was on which profile.

And in case the project has a project specific .zed/settings.json it should load and merge with your current profile but this project specific settings should not allow everything. Example, it should not override themes, or other user specific configuration.

I hope it clarified or even improved what i said earlier.

[seg4lt]

Maybe zed can take some inspiration from VSCode profile feature
https://code.visualstudio.com/docs/editor/profiles

[cole-miller]

Thanks everyone for the feedback. I'm going to convert this to a discussion since that's a better venue for hashing out whether we want a feature along these lines and if so what the design should be.

[mattsays]

Any updates on this?

[Anifyuli]

I waiting this update too

[isFakeAccount]

Profile feature is def one of the best features VSCode offers and it would be pretty great to have it on Zed as well.

[phromo]

My main usage for profiles would be to have an assistant-only mode where I've maximised the size of the agent panel and I use it standalone for general Q&A. Would be nice to be able to start that with zed --profile my-agentic etc.

[adreasnow]

I can't see it documented anywhere but in Zed there's the "switch profiles" command in the command palette, and also if you click on your account picture in the top-right of thew window (ctrl+opt+cmd+P).

This seems to correlate in settings.zed to a block like this:

"profiles": {
  "Home": {},
  "Work": {}
}

And switching profiles seems to apply the settings in those blocks 🙂

[chidniu]

Is there a way to make one of these profiles the default?

[rosavalenzuela23]

Just asking, switching between those profiles also unloads/loads specific extensions?

[Icehunter]

I currently maintain two isolated configurations for Cursor—one for personal work and one for corporate work. This lets me keep API keys, authentication tokens, logins, prompts, and settings completely separate.

_launch_cursor_app() {
    local user_dir="$1"
    shift

    if [[ $# -eq 0 ]]; then
        command cursor --user-data-dir="$user_dir" .
    else
        command cursor --user-data-dir="$user_dir" "$@"
    fi
}

# Personal profile (default "cursor")
cursor() {
  _launch_cursor_app "$HOME/Library/Application Support/Cursor" "$@"
}

# Work profile (short alias "cw")
cw() {
  _launch_cursor_app "$HOME/Library/Application Support/Cursor-Work" "$@"
}

This gives me:

cursor → personal environment
cw → corporate environment

Zed does support an override of the user-data directory, but currently:

• Conversations, prompts, API keys, and various settings are stored inside the Zed config directory
• (e.g., $HOME/.config/zed)
• The user-data directory alone is not enough to separate these kinds of sensitive or identity-specific assets

This makes it difficult to maintain clean personal vs. corporate profiles. Even with a separate user-data directory, both profiles still end up sharing:

• Model/API keys
• Prompt history and conversations
• Editor settings
• AI behavior configuration
• Other identity-linked data

Ideally, Zed would allow something like:

• Personal config dir → $HOME/.config/zed
• Corporate config dir → $HOME/.config/zed-corp

Or a flag/env-var such as:

zed --config-dir=/path/to/alternate/zed-config
ZED_CONFIG_DIR=/path/to/alternate/zed-config zed

Is this possible now?

If not, is support for selecting or overriding the config directory on the roadmap?

Thanks!