Using different themes for different windows

[afiskon]

It would be nice to have an ability to use different themes for different Zed windows.

I keep several projects open in different windows. It would be easier to navigate across them on MacOS if every project had its own theme. I would instantly recognize the project I'm looking for when switching Desktops with the touch pad (or Control+Up arrow).

At the moment it doesn't seem to be possible. When I switch the theme it is changed for all Zed windows at once.

[dlight]

For personal projects, I expected that creating a file .zed/settings.json and adding a theme config would be enough to achieve that. However, while Zed indeed recognizes that file as project-scoped settings (on mouse hover it displays tooltips like "The theme to use for light mode" etc), the theme settings get silently ignored.

The solution I would prefer is local per-project settings overrides (for things like themes, LSP behavior, etc) that lived in ~/.config/zed with a path-based config, so that different people may make different theme choices for the same project (without committing it into the project-scoped config); and generally it would be nice if config were layered like that: the global ~/.config/zed/settings.json has the least precedence, the project-scoped .zed/settings.json has more precedence, but ultimately the personal override ~/.config/zed/settings-overrides.json (keyed by project path) always wins because it has the most precedence, and so the local config of a theme per project lives there.

This file settings-overrides.json could be like this:

{
   "/home/myuser/project": { // (inline config)
      "theme": {
       ...
     },
   },

   "/home/myuser/otherproject": "/home/settings/mycustomzedoverride.json", // separate config file

   "/home/myuser/projects/*" { // (inline config, multiple directories with glob)
      ...
   }
}

(This can be just a section of settings.json too, something like "overrides": { ... })

[afiskon]

TWIMC as a workaround I ended up keeping all Zed windows on the same Desktop. When choosing this desktop I can quickly switch between windows with Command+` (the button near left Shift) in order to find the right one. After discovering this workaround I'm not certain if supporting different themes for different windows would be so beneficial after all. If this is relatively easy to implement, it would be nice to have. If not I guess it doesn't worth it, for my use case at least. Perhaps there are other cases.

[dsegovia90]

Interestingly, if you use the project level .zed/settings.json "theme": "<your theme>" it does not override the global settings. I'm interested in having multiple themes per open window as well, just to quickly identify which editor is which project.

[VojtaStruhar]

Exactly, that would be super neat. Maybe just a colored strip would be enough for me (it's not like I need one project in light mode), but just to quickly differentiate between them

[oluckyman]

Yeah, they say explicitly in the docs, that theme is not overridable.

I'm not sure why or how difficult it is to implement.
But I think having a theme per project is important, as it promotes aesthetics as a core feature of Zed. I personally switched to Zed because of the aesthetics first and only later discovered all the other great features.

[notpeter]

The lack of this feature is reflection of the current settings stack. Currently there is no way for a user to override a project settings in a repo without directly editing that file. When you use the theme selector, it writes your selection to your user settings, but since project settings will override your user settings it would have no effect.

Broadly speaking, .zed/settings.json in a project folder/repo should reflect settings which should ALWAYS apply to that project -- e.g. use these formatter settings, pass these special flags to the LSP, etc. In any project that is used by more than one person, user-specific configuration (vim_mode, theme, buffer_font_size) should be stored elsewhere.

I don't have good sense of the best way to implement this without a bunch of negative consequences. Broadly speaking, I could imagine that per-project settings overrides:

{
  "overrides": {
    "/Users/peter/code/zed": {
      "theme": "One Dark",
      "buffer_font_size": 18
    }
  }
}

Which could work for single-folder / single-file workspaces, but would break for multi-folder workspaces because there's not an easy way to identify those (e.g. "code/folder1,code/folder2") and what would happen if you added a folder to that workspace, would the theme reset? Would it update the overrides key names? (if not, adding a folder would sever existing overrides).

Similarly one could imagine a .zed/whatever_settings.json that should not be checked into source control, that applies user settings on a project basis, but what would you call it? And it would further complicate the existing settings stack:

• Default Settings (default.json in zed repo)
• Global Settings (WIP, /etc/zed/settings.json)
• User Settings (~/.config/zed/settings.json)
• Project Settings (.zed/settings.json)
• SuperUserProject Settings (.zed/super_settings.json)

Setting aside the confusion around harmonization of alternate settings sources (.editorconfig, .prettierrc.json in any folder, including parent folders to projects) you still have the UI confusion -- if I use the theme selector where does it persist those settings? Does it break if there's an override in super_settings? Same with other things which are currently stored in user settings (agent settings, vim_mode, base_keymap, etc) but can be set interactively in the UI (Error: Your super settings and user settings conflict, what do we do now?). Multi-folder workspaces might also conflict -- frontend says "one dark", backend says "one light" what should I do?

Alternatively we could stuff it into the workspace db (currently entirely opaque to the user) but that also feels dirty. My gut is that supporting such a feature a significant rethinking of settings and workspace/project state. Perhaps worth doing, but I don't see any quick wins.

Thanks for reading my ramblings. I'm open to others ideas in the space.
But for the moment, I don't see a design I'd be excited about.

There's an existing feature request for this if you'd like to upvote/subscribe:

• Per-project themes (multiple active themes) #13300

[jecarroll]

Just stumbled across this thread and thought I'd throw in my use-case (which might soon become more common):

I have been a big fan of the Zed AI agent, but I've very recently switched back to Claude Code which has come on a lot since its early beta days. My current workflow involves managing parallel Claude Code agents (currently two), working on separate branches of the same project (using git worktrees). To keep myself sane, I have taken to colour-coding my Mac Terminal windows using Terminal's theming feature. Right now I have a yellow-themed Terminal window with Claude Code working on feature A in one branch and a red-themed Terminal window with Claude Code working on feature B in another branch. The colours are really helping me keep things separate in my mind as I manage these two "employees". When I switch over to Zed to review their code, it would be great if the colour difference could be maintained. In fact, even better would be running Claude Code within Zed's built-in terminal panel, and having the whole window themed. In terms of your implementation head-scratcher above, @notpeter, my use case would need different themes for different branches of the same repo. I'd be happy enough to set these manually and ephemerally on the window, although I guess it would be neater if they could be persisted in settings somehow. Hope this is useful input! :)

[bjackman]

It doesn't address the UI concerns, but what about a .zed/settings.json that's intended to be checked in, and a .zed/settings.local.json that's intended to be .gitignored? I noticed this is how Claude Code operates and I think it's a nice simple option.

[dlight]

I think this two settings setup on each project is awesome for other settings as well (such as LSP server settings), even if in some distant future a better way of per-project theming is found.

I mean if you are editing a project that already has .zed/settings.json but you need to do some local changes to get work done, then you have to resort to performing gruesome git crimes that won't go unpunished.

[ostwilkens]

Lately I have been working in 4-5 workspaces simultaneously, and it gets confusing when every window looks similar. Assigning one theme per context would make it a lot easier to work with. I would love to be able to set theme both in the server-specific and project-specific settings file.

[Ltadrian]

pleasee can someone build this 🙏

[fceruti]

YUP, in the LLM age, this feature is a pretty big deal

[jeremychone]

Yeah, this surprised me. I expected to set font sizes in .zed/settings.json, but no luck.

I use this a lot when recording videos since each project needs different sizes and settings. In VS Code, you can override almost anything.

I might build a small plugin or utility, a zed settings switcher. Keep ~/.config/settings.json and ~/.config/settings-video-demo.json. It would switch settings for all projects, but at least when recording, I get the font size and theme I need.

Hope we can override anything we want in project settings someday.

[dlight]

I might build a small plugin or utility, a zed settings switcher. Keep ~/.config/settings.json and ~/.config/settings-video-demo.json. It would switch settings for all projects, but at least when recording, I get the font size and theme I need.

That's what I do actually.. a shell script like this

#!/bin/bash

setbg() {
    cat ~/.config/zed/original_settings.json | \
        jq -Rs  'include "json5"; fromjson5 | setpath(["theme", "light"]; "'"$1"'") | setpath(["theme", "dark"]; "'"$2"'")' > \
        ~/.config/zed/settings.json
}

if [[ $# -eq 0 ]]; then
    setbg "Base16 Silk Light" "Everforest Dark"
elif [[ $1 == "myproject" ]]; then
    setbg "Base16 Purpledream" "Base16 Purpledream"
fi

This is sufficient (if hacky) if you are working on a single project at a time. The problem is that in the AI era, people want to work with multiple projects at once. And the fundamental reason for that is that agents can be very slow and people are pressed into remaining "productive" at all times rather than whatever they did before when using slow tools.

So it's hard to believe, but this issue is actually an AI feature and probably more impactful than a lot of more visible work.

Still, I wish that when Zed ever gets this feature, it wouldn't be limited to just providing per-project theming. I want full local settings override because it's useful for other things as well.

[brianmhunt]

This feature is the core and essentially only reason I need to use another editor in the AI era. I have many editors open, and I need to immediately be able to visually identify what each is responsible for, and looking at the tiny branch name in the corner is way too time consuming, fickle, and error-prone. If Zed is appealing to people using AI (as it seems to be), this is a pretty hard UX blocker.

[s00500]

This is not just an "AI" workflow issue.

In our current software architecture world I have to

• switch between 1-10 microservices,
• handle infrastructure configs,
• wait on a colleague to test a change I have not yet fully comited,
  and switch between UI and backend submodules of the same project (that I enjoy having in two fully seperate windows with different extensions loaded)

Most of this happens in my normal workflow on different macOS spaces, and when triggering the overview I am hugely reliant on seing all the different color boarders I usually get from the Peacock extension on VSCode.

Most recently VSCode has been crashing a lot for me and I really enjoy the speed of Zed when it comes to starting up and being ready to work.... so this extension (or rather zed feature) would finally enable me to switch 95% of my workflow to Zed...

(I dont wanna sound too complaining, I feel a lot of awesome work is done on Zed and User Feedback is generally heard! i have less and less to complain every time I get back to trying it again ;-) )

[mbanerjeepalmer]

I think as a minimum it would be useful for this to fail loudly when I set it in .zed/settings.json. It has been driving me a bit insane.

[dionysuzx]

+1 would love to see this implemented

[darrenbarklie]

Also advocating for this one. Certainty for agentic engineering, but even working in standard codebases, I often have separate windows for website, web app, API, admin and docs... Very hard to visually distinguish Zed windows when the file tree is all monochrome (which I do like) and the project title text is so small.

[behavio1]

Genuinely frustrating when you have multiple projects open simultaneously — every window is identical.

What's everyone's current workaround?

[maxktz]

you can see workarounds here #13300

[Vany]

#48164 vote plz

[rsieb]

Strong built-in per-project theme support:
✔ VS Code • ✔ JetBrains IDEs • ✔ Sublime Text • ✔ Emacs • ✔ Neovim/Vim (with config)

No native per-project themes:
✘ Zed • ✘ Notepad++ • ✘ TextMate • ✘ Nano/Pico

[lastobelus]

In the agentic era, IDE features are greatly devalued & anything which gives affordance for organization, context-switching, & multi-tasking are of significantly higher value than in the past.

[fceruti]

Maybe in 1.01, Let's go!

[scarpeace]

i would love to see that.

[CaptainCodeAU]

I saw the workaround of keeping all windows on one desktop and using cmd+` to cycle. respectfully that doesn't solve it, it just relocates the problem. cycling through identical looking windows is still cycling through identical looking windows, I still have to read each one to know where I am. the whole point is to NOT have to do that.

Same goes for the separate-instances idea people bring up. running a whole separate Zed per project (separate extensions, login, settings) is a huge amount of overhead for what should be one color value, and the --user-data-dir flag doesn't even handle settings cleanly right now.

For context on why I keep pushing this: I'm dyslexic and have ADHD. color is how I navigate, not decoration. with several projects open at once every window is the same and I lose my place over and over, tab into the wrong repo, etc. a different title bar color per project would just fix it. as you said in the thread, even a colored strip would be enough. it really would.

[42piratas]

#58755