Desktop transcript renders inline code in the error red (legacy --danger-000), with no way to change it

What's wrong

In the Claude Code desktop app, inline code in the transcript is rendered in a red that is visually indistinguishable from the app's error color. Assistant messages are dense with inline code — file names, flags, commands, identifiers — so a normal reply comes out covered in red fragments.

As a user I find this genuinely hard to work with. It reads as if something is constantly failing. In a coding tool the transcript is already full of real errors, real test failures, real red diffs — red carries meaning here, and spending it on ordinary typography makes the whole session feel like an alarm state. I don't know what the right design is, but this isn't it.

The part that frustrates me most is that there is no way to opt out. The desktop app offers only Light / Dark / Match System. No accent choice, no color settings, no legacy theme. This looked fine before, it changed, and there is no way back.

Environment

• Claude desktop app 1.37937.3 (macOS 15, darwin 24.6.0), bundled Claude Code CLI 2.1.246
• Dark theme (userThemeMode: "dark")

Where it comes from

In Contents/Resources/ion-dist/assets/v1/c6a992d55-DvW7AoPn.css, two rules colour inline code from the legacy --danger-000 token:

.ReactMarkdown code    { … color: hsl(var(--danger-000)); … }
div.ProseMirror>p>code { … color: hsl(var(--danger-000)); … }

Resolved values: #f4a9a9 in dark, #8d2525 in light. Error text is now painted from --cds-text-danger (--cds-red-300, #ec7e7e in dark) — a different variable, but close enough that the two are not distinguishable on screen.

This looks like an unmigrated leftover rather than a deliberate choice. Counting consumers across the whole bundle:

• --danger-100, --danger-200, --danger-900 — 0 references
• --danger-000 — 2 references, and both of them are the inline-code rules above

The rest of the UI has moved to the --cds-* system, where a neutral treatment already exists and is not wired up for this surface:

.epitaxy-root                  { --text-assistant-code: hsl(var(--_gray-900)); }
[data-mode=dark] .epitaxy-root { --text-assistant-code: hsl(var(--_gray-100)); }

used by .epitaxy-markdown :not(pre)>code and .epitaxy-code-chip. The editor path also has a purpose-named --cds-editor-code-ink instead of borrowing a semantic token.

What I'm asking for

1. Stop sourcing inline-code colour from the danger palette in the transcript — the neutral --text-assistant-code treatment already shipping in the same bundle would do it.
2. Give desktop users some control over interface colours. The CLI has /theme and custom themes; the desktop app has nothing, and requests for this keep getting closed: #48706 (closed as not planned), #50519, #63020, #76200.

Even a single "neutral code colour" checkbox would be enough. Right now the only way to change it is editing the app's CSS by hand, which breaks on every auto-update.