[FEAT] Add support for custom terminal themes beyond built-in options

I'd like to add some visual context to illustrate why custom theme support is crucial for modern terminal workflows.

The Problem: Dynamic Theme Switching

Modern terminals like Rio, Warp, and others support dynamic theme switching based on system appearance or time of day. When Claude Code's limited theme options conflict with these custom terminal themes, it creates significant usability issues.

Visual Demonstration

Here's a real example from my workflow:

1. Memory feature with theme mismatch - When using a dark terminal theme but Claude Code is still in light mode, the memory feature becomes illegible:

\!Memory feature illegible with theme mismatch

1. The problem: Illegible diffs - When Claude Code shows diffs, the bright green/red colors clash terribly with the dark background, making code nearly impossible to read:

\!Illegible diff with bright colors on dark background

1. The workaround: Manual theme switching - After manually switching Claude Code's theme, the same diff becomes readable:

\!Same diff after manually switching Claude Code theme

Impact on Workflow

This issue significantly disrupts workflow because:

• Dynamic switching breaks constantly: When my terminal automatically switches themes (e.g., dark mode at night), Claude Code's fixed theme suddenly becomes unreadable
• Manual intervention required: I have to stop my work to manually adjust Claude Code's theme multiple times per day
• No perfect match: None of the 6 pre-defined themes properly match my terminal's custom color scheme

Proposed Solution

Allow Claude Code to:

1. Inherit terminal colors directly (respecting ANSI color definitions)
2. Or provide a configuration option to disable Claude Code's color overrides
3. Or support custom theme definitions via configuration file

This would ensure Claude Code integrates seamlessly with any terminal setup, whether using built-in themes, custom themes, or dynamic theme switching.

Related issues: #1185, #1076, #1148

This is definitely needed.

I also have the same problem with claude code being the only terminal program I use which breaks when the system appearance switches.

Terminal programs should always use the fg, bg, and 1-6 color codes by default (as color codes 0 (black), 7 (white), and 8-15 aren't reliable across popular themes, and should support customization using color codes 0-255.

Definitely need this! Being unable to edit the default themes / opt to use current theme seems like a major oversight against what is generally awesome UX.

I also have the same problem with claude code being the only terminal program I use which breaks when the system appearance switches. Terminal programs should always use the fg, bg, and 1-6 color codes by default (as color codes 0 (black), 7 (white), and 8-15 aren't reliable across popular themes, and should support customization using color codes 0-255.

I agree with @net; in fact, I think this is all that's needed.

Use terminal's native colors without override

Modern terminal emulators allow users to conveniently specify 8-16 colors for use across CLIs/TUIs, sometimes shipping with a TUI to select from a large set of standardized colorschemes. Many (eg Kitty, Ghostty) have some form of native dark + light theme support to react to the system's light/dark mode transition.

A new default "system" or "terminal colors" theme in addition to the existing hardcoded color themes would allow users to set colors for their entire shell environment in one place. This has been my biggest pain point with Claude Code since first trying it, personally.

i would also like to see further flexibility in changing the looks of claude.

who can we notify to bump prio on this...the current setup is not workable

Would love to see system added as an option too! I've gotten to a point where I use claude locally even for non coding tasks and I love using both dark+light themes and this is the only thing missing in my setup!

We've developed a tool called tweakcc which can be used to create custom Claude Code themes. You're welcome to try it out!

I just used the Status Line builder to emulate Oh My Zsh with Agnoster. It does look great with the limited colour palette.

The MacOS auto appearance by time of day is also making this quite annoying on my end. Constantly switching between light and dark mode in my claude editor.

I don't know why do anyone complain, at least you have a choice, the VSCode extension just assumes everyone uses dark mode, no option to change. I'm actually surprised they thought of giving users options on terminal.

@erezschatz - That isn't exactly a contribution to this feature request. That line of thinking would also have a statement like this under its umbrella "I don't know why people need Claude Code in the CLI, you can use it in the web interface". I've tested several other AI CLI tools, for example, OpenCode. Every single one except Claude either respects the underlying terminal's theme, has a configurable theme/scheme, or a combination thereof.

Outside of all the already mentioned tangible and objective reasons for a custom theme, here is another one to add to the list: community. Any app/environment/toy that has custom theme configs, skins, whatever it may be... gives rise to the community sharing with each other and interacting. That's always a good thing - for the creators, for the users, and of course for the overlords of the thing being themed.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know.

the issue has not yet been addressed.

All that time spent on my nvim and wezterm setup, only for Claude Code to override it.
As a CLI tool targeting developers, proper theme/color customization should be a basic feature.

first thing i've looked up for claude code is auto theme switching. i also feel like this is something most devs just expect at this point.

in longer conversations it is very hard to distinguish what is what.

• user input
• options
• etc.

When scrolling back this significantly slows us down!

https://github.com/anthropics/claude-code/issues/1076 was on the right track IMO, but was closed as the maintainers cited difficulty detecting color theme across terminals (indeed, acting as a native app in this way is perhaps not the best move).

A common and effective pattern in CLIs/TUIs is the one mentioned above, where a given application either offers no custom color themes at all (as OpenAI’s codex does), or offers a “theme” which does so (sometimes called ANSI or System).

In either case, the result is that the CLI/TUI in question leaves the responsibility for setting/selecting colors up to the terminal it’s running in, and by extension the user. Claude Code already expects the user to set their theme by hand, but it doesn’t currently respect the case where users have done so externally, sometimes painstakingly (as mentioned several times in #1076).

My humble view is that this severely harms the user experience for all but the Pareto majority of users who use their system’s default terminal, with an unconfigured shell.

Each time that I’ve resubscribed to Claude Max, I have delayed until the last possible moment, and then subscribed half-heartedly because of the remembered/anticipated ~pain of quickly starting a task in Claude Code, only to find that I can’t read what’s happening as it works (without waiting or interrupting the task to change the /theme to the other hardcoded light/dark color scheme which is at least readable, but differs aesthetically from every last command-line application in my routine). This issue then recurs ~12 hours later.

Adding a +1 for this feature, specifically for diff background colors.

Currently, the diff view's red/green backgrounds are hardcoded and don't respect:

• The terminal's color palette (even with "ANSI colors only" theme)
• The syntax theme toggle (Ctrl+T in /config → Theme)
• Any env vars like CLAUDE_CODE_SYNTAX_HIGHLIGHT

For users with custom terminal themes (Tokyo Night, Nord, Catppuccin, etc.), the harsh red/green diff backgrounds clash significantly with the rest of the UI.

This was raised in #14144 but that issue was closed when the syntax toggle was added—which only affects code block highlighting, not diff backgrounds.

Would love to see diff colors either:

1. Respect the terminal's ANSI palette when "ANSI colors only" is selected
2. Be independently configurable
3. Pull from the same theme as syntax highlighting

I want to add a real-world accessibility case to this request.

I have Usher Syndrome - I'm legally blind with only 5-10 degrees of central vision, plus hearing loss. I'm not theorizing about accessibility - I live it every day.

The Problem

The blue hyperlinks in Claude Code are extremely difficult for me to read, even with the dark-daltonized theme enabled. That particular shade of blue just doesn't have enough contrast for my vision - I have to strain and squint to make out link text, which slows me down and causes eye fatigue.

What I Need

User-configurable theme colors, specifically:

• Link/hyperlink color (blue is the main problem)
• Or a theme file (~/.claude/theme.json) users can edit

Current Workaround

I have Claude format all links in code blocks like:

→ LINK: https://github.com/...

This works at times, though I have to remind it often, but it would be much better if I could just configure the link color to something I can actually see easily (like bright white or yellow).

Why This Matters

Accessibility isn't just about colorblindness - conditions like Usher Syndrome affect vision in ways that standard "daltonized" palettes don't fully address. User-configurable colors would let people with various vision conditions set what works for them.

Happy to provide more details or test any accessibility improvements.

---
Setup: macOS, iTerm2, Claude Code v2.1.25, dark-daltonized theme

+1 for this! My specific pain point is diff highlighting colors.

• Dark mode's added/removed line backgrounds are too intense and strain my eyes
• ANSI-only mode lacks diff background colors entirely, which is inconvenient
• Dark mode (colorblind-friendly) has a color scheme that doesn't match my preferences

A partial customization option would be ideal:

{
  "theme": {
    "base": "ansi-only",
    "overrides": {
      "diffAddedBackground": "rgba(0, 255, 0, 0.1)",
      "diffRemovedBackground": "rgba(255, 0, 0, 0.1)"
    }
  }
}

Related: #22367

Any idea if this will be done?

Use case: tmux inactive pane dimming

tmux's window-style/window-active-style allows setting different background colours for active vs inactive panes. a useful visual cue when working with multiple panes. For example:

  set -g window-style "bg=#1d1f21"
  set -g window-active-style "bg=#292c33"

This works for standard shell sessions and most CLI tools, but Claude Code explicitly sets its own background colour, which overrides tmux's default background (SGR 49). The result is that Claude Code panes don't dim when unfocused, making it harder to tell which pane is active.

A "use terminal default background" option or a transparent/no-background theme would fix this and likely also address the transparent terminal requests in this thread.

I'd like to see automatic theme switching based on system appearance. macOS exposes this via AppleInterfaceStyle, and terminals like Ghostty already support dark:X,light:Y theme declarations. Claude Code is the only terminal tool I use that requires manual /theme toggling when the OS switches appearance.

See also #11813 and #16769, both closed as duplicates without linking back here.

Just give us the ability to put our own color values in some JSON file. Something changed recently, and Claude Code just looks ugly in my personal setup.

Something changed recently

Same here

@philoserf

I'd like to see automatic theme switching based on system appearance. macOS exposes this via AppleInterfaceStyle, and terminals like Ghostty already support dark:X,light:Y theme declarations. Claude Code is the only terminal tool I use that requires manual /theme toggling when the OS switches appearance.

XTerm defined OSC 10, which many terminals implement. It goes something like OSC "10;?" ST, and the terminal replies with OSC "10;rgb:" RRRR "/" GGGG "/" BBBB ST. So this should all be possible for Claude CLI to do.

Until Claude Code supports custom themes natively, you can control the appearance through your terminal's theme:
Approach 1 — ANSI mode + terminal theme:
Claude Code offers "Light mode (ANSI)" and "Dark mode (ANSI)" which use your terminal's color palette. By customizing your terminal's 16 ANSI colors, you effectively theme Claude Code:

• iTerm2: Preferences → Profiles → Colors → Color Presets → import any .itermcolors file
• Alacritty: ~/.config/alacritty/alacritty.toml → [colors] section
• Kitty: ~/.config/kitty/kitty.conf → color0-color15 settings
• Ghostty: ~/.config/ghostty/config → palette settings
• Windows Terminal: settings.json → schemes array

Popular theme collections: iTerm2-Color-Schemes has 300+ themes in formats for every terminal.
Approach 2 — Environment variable override:

export CLAUDE_THEME=ansi-dark  # or ansi-light

Approach 3 — CSS override for VS Code Native UI:
If using the VS Code extension in Native UI mode, the appearance follows your VS Code theme. Switching VS Code themes (e.g., Dracula, Monokai, Solarized) changes Claude Code's appearance.
Popular combos that work well:

• Catppuccin (any terminal) → Claude ANSI mode → soft, readable colors
• Solarized Light/Dark → good contrast for code blocks
• Dracula → good for long sessions (low eye strain)

The absence of native theme customization has a concrete downstream effect worth noting: the third-party tool tweakcc (npm) exists almost entirely to fill this gap. Its most-used feature is colorizing submitted user messages in the conversation history — exactly the scrollback navigation use case described in this issue.

The problem is that tweakcc works by binary-patching Claude Code's embedded JavaScript bundle. It works reliably on 2.1.78, but breaks on 2.1.84+ because Anthropic changed how the JS bundle is packaged in the native installer (moved from ELF overlay to an ELF section). Users who rely on this feature are now pinned to 2.1.78.

That's the real cost of the gap: people binary-patching older versions of the app just to get a color on their own messages. A single settings.json entry — "userMessageColor": "cyan" — would eliminate the entire workaround class.

My use case: I use Ghostty on macOS with auto-switching between two themes tied to the system appearance mode:

• Light → Rose Pine Dawn
• Dark → Terafox

Ghostty handles the switch natively via its theme = light:rose-pine-dawn,dark:terafox config. Everything else in my terminal (Neovim, fzf, lazygit, etc.)
follows this automatic light/dark transition seamlessly, because it all reads from the terminal palette.

Claude Code is the one tool that doesn't keep up. I switch between modes several times a day based on ambient light conditions (bright daylight vs.
evening/night), and every transition forces me to manually type /theme and pick the matching variant. For long sessions that cross a lighting change, this is
a real friction point.

What would solve it: a theme: "auto" option in settings.json that detects the macOS appearance mode (or listens to AppleInterfaceThemeChangedNotification)
and applies the matching preset dynamically, without needing to restart the session or type /theme manually.

Current workaround: a zsh wrapper that rewrites settings.json at launch:

```
claude() {
local theme settings="$HOME/.claude/settings.json"
if osascript -e 'tell application "System Events" to tell appearance preferences to get dark mode' | grep -q true; then
theme="dark"
else
theme="light"
fi
jq --arg t "$theme" '.theme = $t' "$settings" > "$settings.tmp" && mv "$settings.tmp" "$settings"
command claude "$@"
}

  It works at startup, but it can't refresh a running session — only a native theme: "auto" can.

  Bonus note: I originally tried light-ansi to stay consistent with my terminal palette, but ran into #40905 (inline code unreadable because the theme uses
  ANSI color 7 which maps to a near-white background color on light palettes). So light-ansi isn't a viable escape hatch for users with custom light themes.

This is a duplicate of #50950, which was fixed as of version 2.1.118.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.