Desktop app: support custom themes / accent colors (parity with CLI custom theme system)

Status Open
Reported on v2.1.215
Maintainer reply None cached
Activity 18 comments · opened Jul 20, 2026

Problem: The desktop app offers only light/dark (+ high-contrast). With most modern apps shipping visually identical near-black dark modes, Claude Desktop windows are indistinguishable at a glance from other apps across multiple monitors — color is how many users recognize windows without reading title bars.

Request: Let users re-color the desktop app chrome (sidebar / chat background / accent), ideally reusing the existing ~/.claude/themes/*.json custom-theme system the terminal CLI already supports, or at minimum an accent-color picker. The Code-appearance syntax themes (e.g. Catppuccin) already prove out per-surface theming — extend it to the app UI.

Environment: Claude Desktop on macOS 15 (Darwin 24.6), Claude Code engine 2.1.215.

(Searched existing issues — all current custom-theme issues concern the CLI/TUI theme system; none request desktop chrome theming.)

View original on GitHub ↗

18 Comments

azinzuvadia-git · 1 month ago

The recent theme change in Claude and Claude code app for Windows 11
When you have with dark theme on - the responses now add a red font to all inline code or file name parts. This is extremely distracting while trying to read the response. Your eyes see red and you cannot focus fully on the normal text. Cant we go back to the previous light grey or white font for the inline code or file names and / or cant you give me an option to customize this myself? I cannot stare at such text responses for the 8hr work day.

<img width="3840" height="2076" alt="Image" src="https://github.com/user-attachments/assets/c9508797-4ed9-49af-8012-3a81153f3cf9" />

ppercree · 1 month ago

you can add your own themes using tampermonkey in google, would be cool to have custom desktop themes though

cmcgarr1 · 1 month ago

+1. My concrete use case: I run many Code-tab sessions at once, each on a different project, and I want a per-session background or accent color (one chat blue, one red) so I can tell them apart at a glance without reading the title. A global custom theme would be a good first step, but per-session color is the thing that would actually help with parallel sessions. This is the same ask as #52157, which was closed as a duplicate pointing here.

cmcgarr1 · 1 month ago

Findings from a DevTools poke, plus a proposal

In the desktop Code tab, each session renders inside div.dframe-pane[data-pos="0:0"] (role="region", aria-label="Primary pane"). The session id is only in the route, claude.ai/epitaxy/local_<uuid>; the pane element itself carries no session attribute. So nothing, inside or outside the app, can style one session differently today, and with two panes open the URL only names one of them.

Proposed change

  1. Stamp data-session-id on .dframe-pane from the pane model that already knows it.
  2. Add an optional accentColor to session metadata. Default: a hue hashed from the session id, so every new session gets a distinct color automatically with zero setup. Override from the session's right-click menu next to Rename.
  3. Expose it as one CSS variable on the pane (--pane-accent) and use it for a 3px inset edge and a ~12% wash over the pane. Show the same color as a dot on the sidebar row and tab.
  4. Falls back to the current global theme when the feature is off.

Demo, runnable now

With allowDevTools: true in developer_settings.json, paste this in the Console. Every session gets its own stable color and it flips as you switch sessions. It dies on restart and can't tell two panes apart, which is exactly what steps 1 and 2 fix.

(()=>{const hue=id=>{let h=0;for(const ch of id)h=(h*31+ch.charCodeAt(0))>>>0;return h%360};let s=document.getElementById('pane-tint')||document.head.appendChild(Object.assign(document.createElement('style'),{id:'pane-tint'})),last;const apply=()=>{const id=(location.pathname.match(/local_[0-9a-f-]+/)||[])[0];if(!id||id===last)return;last=id;const h=hue(id);s.textContent=`.dframe-pane[data-pos="0:0"]{box-shadow:inset 0 0 0 3px hsl(${h} 70% 55%);border-radius:12px}.dframe-pane[data-pos="0:0"]::after{content:'';position:absolute;inset:0;background:hsl(${h} 70% 55% / .12);pointer-events:none;z-index:9999;border-radius:12px}`};apply();setInterval(apply,500);return 'hashed tint on'})()
arminfuerst · 1 month ago

Adding a use case that I think is stronger than distinguishability, because it's a correctness problem rather than a personalization one: the desktop app gives no indication of window focus state on Windows.

On Windows 11, Settings → Personalization → Colors → "Show accent color on title bars and window borders" is not decoration — it is the OS-level focus affordance. With it enabled, the active window's title bar is accent-colored and inactive windows are grey. For users who rely on it, that color is the focus indicator; there is no secondary cue.

Claude Desktop draws its own title bar and ignores this setting, so its title bar looks identical whether the window is focused or not. The failure mode isn't cosmetic:

  1. Enable "Show accent color on title bars and window borders".
  2. Place the Claude window over another app that has blue content near the top of its window.
  3. Look away, then come back and try to drag Claude by its title bar.

Because Claude's own title bar carries no focus color, the blue area belonging to the other app reads as the active title bar. Every click there hits the background app instead, raising it and sending Claude behind it. I repeated this several times before working out that Claude simply wasn't honoring the setting — the window kept "disappearing" and there was no visual feedback explaining why.

So beyond a theme system or an accent picker, the minimum fix is: respect the Windows accent-on-title-bar setting, or otherwise visually differentiate the focused from the unfocused state (e.g. a distinct title bar / border treatment on blur). That's arguably an accessibility issue, not just a styling preference.

ghost · 1 month ago

Same request from Windows, where the case is a bit sharper.

On Windows, Claude Desktop ships as a signed MSIX package (mine is Claude_1.52386.0.0_x64__pzs8sxrjxfjjc under C:\Program Files\WindowsApps). There is no reachable app.asar, so the community workarounds that exist on macOS, such as patching the Electron bundle to inject CSS, are not available here at all. Doing it would require taking ownership of a system protected folder and breaking the package signature, which I would not suggest to anyone. So on Windows there is no workaround, only this request.

My use case is the one already described, plus one more. I recently themed the rest of my desktop around a single palette: window frames, taskbar, Start menu, file manager, and every app that has a port of that palette. Claude Desktop is now the only window that does not match, and on a large screen with several windows open it is also the hardest one to pick out.

An accent color picker alone would cover most of this. Reusing the existing theme JSON files would cover all of it.

One small thing: this issue is labelled platform:macos, but the request is not macOS specific. Could that label be widened?

MadisHurt · 1 month ago

Adding a strong +1 here from a daily user's perspective.

The Desktop app already has all the plumbing for this — Claude Code (the CLI) ships a full custom-theme system (/theme, custom JSON theme files, CSS-variable-driven design tokens). The Desktop app's own renderer is already built on CSS custom properties (--cds-* tokens) for every color in the UI — the theming mechanism is architecturally present, it's just not exposed to users.

Right now Desktop is locked to light/dark/system with zero further control: no accent color, no custom palette, no way to match a personal setup. For a tool people spend hours a day inside, that's not a cosmetic nice-to-have — it's a real accessibility and personalization gap, and it's inconsistent with the CLI's own product that already solves this.

Concrete ask: expose the existing --cds-* token system to a user-writable theme file (mirroring the CLI's theme JSON approach), even in a minimal first pass — accent color + background + text would already close most of the gap. Given the tokens already exist in the codebase, this reads like a scoping/priority gap rather than an engineering one.

reximus-bbs · 28 days ago

+1 — would love custom accent/palette support in the desktop app for parity with the CLI theme system. Catppuccin Mocha specifically would be a popular pick.

jaejoe · 23 days ago

Another strong +1 here.

My use case is a bit different however. I'm prone to migraines on a semi regular basis, typically multi-day events that make me extremely light sensitive. In order to keep working while dealing with them I need to be able to adjust the coloring of the app to something that is easier for me to handle. And yes while "dark" helps it's actually worse in some cases because it can make things too high contrast.

sarimarton · 13 days ago

Absolutely a must-have feature, as the daily workflow is being steered into the Desktop app. The Code section with the SSH sessions, diff viewer, terminals etc. makes this app the central app in a developer's life, this is THE IDE. We need themes. I can't stand the brownish color.

zachariahismyname · 12 days ago

+1
The current theme color limitations are hard on my eyes and ability to read the screen, especially long blocks of text. Even just background and general text color adjustment (like available in codex) would be hugely beneficial. After adjusting on codex, it is sooo much easier on my eyes.

Tuguldurbayarco · 8 days ago

+1
for me, I would like to change the theme of claude desktop app similar with my VSCode, Cursor theme which being used for a long time. For example If I read a chat and code that opened in the Claude Desktop App's side bar are same theme like Dark Modern, there will be no need to switch to other softwares to read codes.

Statusnone420 · 8 days ago

+1 from Windows 11 (desktop app, Code tab), with a specific use case: OLED monitors.

The current dark theme is dark grey, not black, so the whole window stays lit. On OLED this looks washed out next to true-black apps on the same screen, and keeps a large static area (sidebar, background) lit for hours, which adds burn-in risk. Screenshots below: Claude desktop (top, dark grey) vs. ChatGPT desktop (bottom, true black).

Even before full custom themes, a built-in "Black (OLED)" option next to Light / Dark / System would solve this:

  • Background, sidebar, chat area: #000000
  • Composer, cards, menus: about #111111–#1a1a1a
  • Text and accents: unchanged

This differs from #53154 (which asked for grey instead of black on macOS). An option serves both groups.

(Usage stats card blurred out for privacy. The background colour around it is unedited.)

<img width="1471" height="1131" alt="Image" src="https://github.com/user-attachments/assets/a3515609-4fcc-4fbf-a9ec-3da43fb28b63" />
<img width="1557" height="1019" alt="Image" src="https://github.com/user-attachments/assets/356f1fa6-8547-494e-b62a-6b14f59c99be" />

donaticg-jpg · 7 days ago

+1 from a daily Desktop (Code tab) user on Windows. I set up a custom palette for the CLI via a Windows Terminal color scheme plus the ANSI theme, and it would be great to carry that same look into the Desktop app. Ideally the Desktop app would read the same theme files as the CLI (~/.claude/themes/*.json) so one theme works everywhere. Even accent color plus background/foreground overrides would cover most of it.

jyotman · 4 days ago

@bcherny this would be so helpful to have. I'm using claude code desktop app whole day, and I really want low contrast themes, which are easy on the eye 🙏

ssenvar · 3 days ago

+1 It's not a rocket science! Plsss

maximebories · 3 days ago

Same here, can't easily distinguish Claude Desktop from other applications. I made a tweak in the meantime maximebories/claude-desktop-clay-theme, I use it in light mode only and it needs more work but it'll do until Anthropic implement it.

lorenzo-cm · 8 hours ago

+1