dark-ansi theme: expanded message background (userMessageBackgroundHover) collides with subtle/inactive text on color7, making expanded tool calls unreadable in fullscreen

Summary

In fullscreen rendering mode, the dark-ansi theme maps the expanded message background and the dimmed text colors to the same ANSI slot (color7). Expanding a message (e.g. clicking a Bash tool call) therefore renders text on a background of an identical or near-identical color, making the expanded content unreadable.

This is the same class of bug as #40905 (which concluded "Dark mode correctly separates concerns"). That is no longer true now that the fullscreen background tokens exist.

Root cause

The dark-ansi preset defines:

| Token | Value | Role |
|---|---|---|
| userMessageBackgroundHover | ansi:white (color7) | background behind a hovered or expanded message |
| subtle | ansi:white (color7) | faint borders, de-emphasized secondary text |
| inactive | ansi:white (color7) | hints, timestamps, disabled items |
| text | ansi:whiteBright (color15) | default foreground text |
| selectionBg | ansi:blue | mouse selection background |

userMessageBackgroundHover collides with subtle and inactive on color7. Because both sides resolve to the same ANSI slot, the collision is palette-independent — it reproduces on any terminal color scheme, since no palette can make color7 contrast with color7.

text (color15) sits on userMessageBackgroundHover (color7). In every conventional palette color15 and color7 are both light, so this pair is also very low contrast.

Confirmed against the shipped binary (v2.1.207). The expanded state is driven directly by this token:

backgroundColor: expanded ? "userMessageBackgroundHover" : void 0

Concrete numbers (Base16 Eighties palette)

• color7 = #D3D0C8, color15 = #F2F0EC
• Expanded background: #D3D0C8
• subtle / inactive text: #D3D0C8 → contrast 1.0:1 (literally the same color)
• text: #F2F0EC on #D3D0C8 → contrast 1.15:1

WCAG AA requires 4.5:1.

Because selectionBg is ansi:blue, dragging the mouse over the region repaints the background and the text becomes readable — a useful confirmation of the diagnosis, and the only current workaround without changing themes.

Reproduce

1. /theme → Dark mode (ANSI colors only)
2. /tui fullscreen (or set CLAUDE_CODE_NO_FLICKER=1)
3. Run any Bash tool call
4. Click the tool call in the transcript to expand it
5. The expanded detail region renders light-on-light and is unreadable

Expected

Background tokens and foreground tokens should never resolve to the same ANSI slot. dark-ansi should draw its fullscreen backgrounds from the dark end of the palette, mirroring how it already separates text (color15) from userMessageBackground (color8).

Suggested minimal fix — reassign the collided token:

userMessageBackgroundHover:  ansi:white  →  ansi:black   (color0)

…paired with a distinct value for bashMessageBackgroundColor, which currently already uses ansi:black, so that hovering a Bash entry still produces a visible state change. More generally, all six fullscreen tokens (userMessageBackground, userMessageBackgroundHover, messageActionsBackground, bashMessageBackgroundColor, memoryBackgroundColor, selectionBg) should be constrained to background-appropriate slots (color0 / color8) in dark-ansi, and to color7 / color15 in light-ansi.

Workaround

A custom theme overriding only the fullscreen tokens restores readability (requires ≥ v2.1.118):

// ~/.claude/themes/dark-ansi-fullscreen-fix.json
{
  "name": "Dark ANSI (fullscreen-safe)",
  "base": "dark-ansi",
  "overrides": {
    "userMessageBackground":      "#2D2D2D",
    "userMessageBackgroundHover": "#3F3F3D",
    "messageActionsBackground":   "#4A4A48",
    "bashMessageBackgroundColor": "#242424",
    "memoryBackgroundColor":      "#2D2D2D",
    "selectionBg":                "#515151"
  }
}

This sacrifices the palette-following property that is the entire point of an ANSI theme, so it is a mitigation rather than a fix.

Environment

• Claude Code 2.1.207 (native binary, linux)
• Theme: dark-ansi
• tui: "fullscreen"
• Windows Terminal → WSL2 (Ubuntu 22.04) → tmux
• TERM=tmux-256color, tmux Tc capability true
• Terminal color scheme: Base16 Eighties (bug is palette-independent — any scheme reproduces it)