[Bug] Custom themes diff overrides not applying

That diff screenshot was during testing the new theme

Having the same prob!

same bug, confirming on a different setup:

• Claude Code v2.1.140
• Ghostty 1.3.1 (TERM=xterm-ghostty, COLORTERM=truecolor)
• macOS Darwin 24.6.0

custom theme overrides for all 6 diff keys (diffAdded, diffAddedDimmed,
diffAddedWord, diffRemoved, diffRemovedDimmed, diffRemovedWord) silently
ignored. Other theme tokens (userMessageBackground, promptBorder, claude,
etc.) apply correctly from the same file.

another testing note: switching the theme's base from "dark" to
"light" DOES change the diff colors (to the built-in light defaults).

Confirming this on Linux with the latest release — the existing reports are all macOS, so adding a different platform/terminal as another data point.

Environment

• Claude Code v2.1.156 (current latest)
• Linux (CachyOS, kernel 7.0.5), Wayland / Hyprland
• Running inside tmux: TERM=tmux-256color, COLORTERM=truecolor; verified true 24-bit RGB passes through (client_termfeatures includes RGB, setrgbf/setrgbb present)

Repro: custom theme at ~/.claude/themes/<slug>.json, selected via "theme": "custom:<slug>" in settings.json. All six diff overrides — diffAdded, diffRemoved, diffAddedWord, diffRemovedWord, diffAddedDimmed, diffRemovedDimmed — are silently ignored. Every other token in the same file (claude, text, userMessageBackground, promptBorder, success, error, …) applies correctly.

I double-checked the override values are well-formed and the keys are the documented ones; the diff simply renders with the base theme's built-in defaults instead of the overrides. This lines up with @amzock's note that flipping base dark↔light shifts the diff colors — to the built-in defaults, never to the custom values.

So this looks like a TUI logic bug independent of platform/terminal/truecolor: the diff-color path isn't wired to the custom-theme overrides. Still reproduces on the latest release (2.1.156).

I can still reproduce this issue with Claude Code v2.1.179, Linux 7.0.12-101.fc43.x86_64.

Still having this issue on Claude Code 2.1.186 on MacOS 26.5

same issue with claudecode version 2.1.202

Still present in v2.1.206 (macOS, Ghostty). I dug into the compiled binary and found the root cause; identifiers below are from the minified v2.1.206 bundle.

There are two token-resolution paths, and only one of them knows about custom themes:

1. React theme context (healthy): the provider computes the active theme by merging the custom theme's overrides onto its base preset (C0i(EZ(base), overrides)). Anything rendered through this path — transcript +N/−N diff counters, dialog borders, labels — honors overrides correctly.

1. Low-level color applier (buggy): a closure of the form

``js
function Yn(e, t, r = "foreground") {
return (n) => {
if (!e) return n;
if (e.startsWith("rgb(") || e.startsWith("#") || e.startsWith("ansi256(") || e.startsWith("ansi:"))
return p3e(n, e, r);
return p3e(n, EZ(t)[e], r); // ← token name resolved here
};
}
``

When e is a token name (e.g. diffAdded), it resolves via EZ(t), and EZ is a switch over only the six built-in presets:

``js
function EZ(e) { switch (e) {
case "light": ...; case "light-ansi": ...; case "dark-ansi": ...;
case "light-daltonized": ...; case "dark-daltonized": ...;
default: return K_h; // dark preset
}}
``

A custom:<slug> setting is at best normalized to the custom theme's base first (rq() → getCustomThemeBase() || "dark"). The theme's overrides are never consulted on this path.

The Edit permission dialog's diff line backgrounds go through path 2, which explains both symptoms reported here: diff overrides are silently ignored, and changing the custom theme's base does change the diff colors (to that preset's stock values) — confirming the base is the only part of a custom theme this path sees.

Easy repro of the split: with a custom theme overriding diffAddedWord, trigger any file-edit permission prompt. The +N counter in the transcript uses the override while the word highlight inside the dialog's diff uses the base preset — same token, two colors.

Suggested fix: have path 2 resolve tokens against the same merged theme object the provider computes (or teach EZ to consult the loaded custom-theme cache), rather than mapping custom:* to a built-in preset.

I believe I found another yet-unmentioned repro condition: this only happens with syntax highlighting on (default) — pressing ctrl+t to disable it makes the custom diff overrides apply correctly, so highlighting is what selects the buggy path for diff line backgrounds.