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

Summary

Inline code in Claude's markdown output (` file names , variables , quoted values , etc.) is rendered with a color that **cannot be changed by a custom theme's overrides**. The renderer reads the color from the fixed *base* palette by name, bypassing the merged theme entirely. There is also no dedicated theme key for inline code — it reuses permission`.

Current behavior (v2.1.199)

The codespan handler resolves its color like this:

case "codespan": return xo("permission", t)(e.text)
// xo(key, t)  ->  eLe(text, mJ(t)[key], ...)
// mJ(name): switch(name){ case "dark-ansi": return <fixed palette>; ... }

t is the base theme name (e.g. "dark-ansi"), so the color comes from mJ("dark-ansi").permission, i.e. the hardcoded base value. A custom theme like:

{ "name": "mytheme", "base": "dark-ansi", "overrides": { "permission": "ansi:cyan" } }

loads correctly (the file is read at startup) and the override does apply to UI chrome such as permission prompts — but the markdown renderer never consults the merged theme, so inline code stays the base color.

Impact

• Inline code color is effectively un-themeable.
• It's tied to permission, so it can't be distinguished from the permission-prompt accent color.
• On terminals with a non-standard ANSI palette this is surprising — e.g. base permission = ansi:blue, rendered bold, resolves to the terminal's intense-blue slot, which may not match the user's intent and can't be corrected in-app.

Requested change (either would resolve it)

1. Pass the merged/override-applied theme to the markdown renderer so overrides affect codespans (and other markdown-rendered colors); and/or
2. Add a dedicated theme key (e.g. codeSpan / inlineCode) so inline code can be colored independently of permission.

Environment

Claude Code 2.1.199, Linux, TERM=rxvt-unicode-256color, custom dark-ansi-based theme.