[BUG] /color session palette desaturated since 2.1.78 (still broken in 2.1.140)

Description

The /color command's session-color palette renders desaturated/washed-out in 2.1.140 on a truecolor-capable terminal. Setting blue produces a pale cornsilk/baby blue instead of a deep saturated blue. orange looks like pale tomato. Cycling through red / yellow / green shows the same shift — every color in the palette has lost saturation and gained brightness.

This is almost certainly the same root cause as #35806 (statusline RGB colors washed out since 2.1.78). That issue identifies the 2.1.78 changelog entry — _"Fixed washed-out Claude orange color in VS Code/Cursor/code-server terminals that don't advertise truecolor support"_ — as the suspected regression: the truecolor downgrade is being applied globally rather than only on terminals that don't advertise truecolor support.

Filing this as a separate issue because:

• #35806 is scoped to the custom statusline RGB surface
• This one is the built-in /color session palette — a different surface, likely same underlying renderer bug

If maintainers want to dedupe, happy to defer to #35806 — but the session-color surface affects every Claude Code user who uses /color, not just custom-statusline users, so it may be worth tracking separately for priority signal.

Environment

• Terminal: iTerm2 (truecolor-capable), COLORTERM=truecolor
• OS: macOS (Darwin 25.3.0, arm64)
• Claude Code: 2.1.140
• Previous working version (per #35806): 2.1.77

Repro

1. Open Claude Code in a truecolor-capable terminal (iTerm2, Ghostty, etc.)
2. Run /color blue
3. Observe: session indicator is pale/washed-out, not the deep blue you'd expect from blue
4. Try /color orange — pale tomato, not orange
5. Try /color yellow, /color red, /color green — all desaturated

Expected

/color blue produces a saturated blue matching what the ANSI/truecolor blue value should render in the terminal. Same for every other named color in the palette.

Related

• #35806 — Custom statusline colors washed out in truecolor terminals since 2.1.78 (likely same root cause)
• #44423 — Feature: custom border/frame color in settings.json (workaround request)
• #50818 — Per-component UI color customization (workaround request)

A user-overridable palette (per the workaround requests) would also mitigate this — if I can set my own RGB values for the session-color named slots, the renderer's global desaturation matters less. But the underlying truecolor regression is still worth fixing.

Asks

1. Fix the 2.1.78 global desaturation regression — scope the VS Code/Cursor/code-server truecolor downgrade to terminals that actually need it (those not advertising truecolor support), not unconditionally.
2. Failing that, allow user-supplied palette overrides in settings.json so users can pin their preferred RGB values for the named session colors (see #44423 / #50818).