Markdown inline code (codespans) ignore custom theme overrides — make the color themeable

Confirming this on 2.1.211 (macOS, custom theme based on light), with one additional detail: for custom themes the fall-through is worse than "base palette" — it resolves to the dark table regardless of the theme's declared base.

In the 2.1.211 bundle the chain is (identifiers differ from the 2.1.199 report but the structure is identical):

case "codespan": return Xn("permission", t)(e.text)

function Xn(e, t, r = "foreground") {
  return (n) => {
    if (!e) return n;
    if (e.startsWith("rgb(") || e.startsWith("#") || e.startsWith("ansi256(") || e.startsWith("ansi:"))
      return h5e(n, e, r);
    return h5e(n, HV(t)[e], r);   // <-- looks up the *stock* table by theme name
  }
}

function HV(e) {
  switch (e) {
    case "light": return qpg;
    case "light-ansi": return jpg;
    case "dark-ansi": return Wpg;
    case "light-daltonized": return Gpg;
    case "dark-daltonized": return zpg;
    default: return Vpg;          // <-- dark table
  }
}

t here is the theme name. For a custom theme ("theme": "custom:rose-pine-dawn") the name matches no case, so HV returns the dark table and inline code renders as dark's permission = rgb(177,185,249) — a bright periwinkle — even though the theme declares "base": "light" and overrides "permission". On a light background this is the most visually broken markdown element in an otherwise fully-overridden theme.

So there are two layered problems:

1. The markdown renderer never sees the merged theme (this issue's original report) — overrides are bypassed.
2. Unknown (custom) theme names hit the switch default, so custom themes don't even inherit their declared base's value — they always get dark's.

No workaround exists on the user side: the color is emitted as a truecolor SGR sequence, so terminal palette remapping can't intercept it either.

Repro:

// ~/.claude/themes/repro.json
{ "name": "repro", "base": "light", "overrides": { "permission": "#907aa9" } }

Set "theme": "custom:repro", have Claude emit ` inline code : permission prompts render #907aa9, inline code renders rgb(177,185,249)`.

Confirming this is still present in v2.1.220 on macOS (issue is currently labelled platform:linux, but it's platform-independent — the colour is baked in by the renderer, not negotiated with the terminal).

Two things that might help whoever picks this up.

The merged palette is already available at the call site

The theme context provider exposes both forms side by side:

{
  themeSetting,
  currentTheme:  LJr,   // the base NAME, e.g. "dark-ansi"
  resolvedTheme: BNu,   // = Dcs(tY(LJr), activeCustomTheme?.overrides)  <- merged
  activeCustomTheme: _Ht,
  ...
}

The markdown path takes the first one — callers do const [cXf] = is() (which returns currentTheme) and pass it down through yvr(content, cXf, highlight) → f$(token, t) → to("permission", t). So to() receives a base name and re-derives the palette with tY(t), discarding the overrides that resolvedTheme already applied.

to() also already accepts literal colour strings:

function to(e, t, r = "foreground") {
  return (n) => {
    if (!e) return n;
    if (e.startsWith("rgb(") || e.startsWith("#") || e.startsWith("ansi256(") || e.startsWith("ansi:"))
      return iVe(n, e, r);
    return iVe(n, tY(t)[e], r);   // <-- only path that needs to change
  };
}

so threading resolvedTheme through instead of currentTheme (and letting to() use t directly when it's already a palette object rather than a name) looks sufficient.

The blast radius is one key

In 2.1.220, permission is the only theme key still resolved inside the markdown renderer — every other bit of markdown styling in f$() goes through bold / dim / italic / strikethrough, which carry no colour. So this is narrower than the older #52465, whose other slots (text, error, warning, success, …) appear to have been fixed already; codespans are the last one on that path.

Workaround for anyone hitting this now

Since the colour comes from tY(base), the base you declare does still control it. Picking an ANSI base (dark-ansi / light-ansi) makes permission resolve to ansi:blueBright, which defers to the terminal's own palette instead of hardcoding the built-in dark periwinkle rgb(177,185,249). That's not themeable per-se, but for anyone generating Claude Code themes from an existing terminal colour scheme it at least keeps inline code inside the scheme's palette. An rgb base (dark / light) cannot be corrected at all.

Agreed on the dedicated inlineCode key in the request above — sharing permission with the permission-prompt accent means you can't give inline code its own colour even once overrides work.

Still reproduces on 2.1.260 (issue was filed against 2.1.199), on a different base preset and a different terminal — so this isn't specific to dark-ansi or to unusual ANSI palettes.

Environment: Claude Code 2.1.260, WSL2 (Ubuntu) on Windows Terminal, TERM=xterm-256color, COLORTERM=truecolor, custom theme with "base": "dark".

The code path is unchanged, only the minified identifier differs:

// 2.1.199 (original report)
case "codespan": return xo("permission", t)(e.text)
// 2.1.260
case "codespan": return ut("permission", t)(e.text)

Isolating it: I set 57 of the 72 documented tokens to #FF0000 in an active custom theme (confirmed selected via /theme → Using custom theme "Vesper"). Every other piece of UI text turned red; inline code kept its
default blue. So the merged theme is applied correctly everywhere except this path — which matches the diagnosis in the original report.

One detail that might help narrow it down: sampling the rendered inline code from a screenshot gives ≈ #B3DCFF. With "base": "dark" I'd expect permission = rgb(177,185,249) (#B1B9F9) from the bundled palette, but the
green channel is well off. The closest value I can find in the 2.1.260 bundle is rgb(183,224,255) (#B7E0FF), which appears as permissionShimmer in one of the presets. I'm not confident enough to call this a second
bug — it may just be bold rendering — but if the codespan path resolves against a preset or variant other than the one the theme declares, that would be worth checking alongside the main fix.

Either requested change in the original post would resolve it for me; a dedicated inlineCode token would be the more useful of the two, since inline code appears constantly in normal output while permission is a
dialog accent, and the two shouldn't have to share a color.