[FEATURE] Render color swatches next to color codes in assistant output

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's TUI strips ANSI escape sequences from assistant message text, so there's no way to show a color swatch next to a color literal the way VS Code's color decorator does.

Claude emits color codes constantly - CSS, theming, design tokens, chart palettes, terminal config.
Today the only way to see what #2E86AB actually looks like is to copy it into another tool.
Reviewing a proposed palette of six colors means six round trips out of the session.

The capability gap is only in the renderer, not the terminal:

• Bash tool output renders 24-bit ANSI correctly. printf '\033[48;2;255;107;53m \033[0m' from the Bash tool shows an orange block.
• The identical sequence in an assistant message renders as literal text: [48;2;255;107;53m.

So the terminal supports truecolor and the transport supports it. Only assistant-text rendering drops it.

Proposed Solution

Have the TUI renderer detect color literals in assistant message text and draw a small colored block next to each one, matching VS Code's color decorator.

Detection should cover the common CSS forms:

• Hex: #RGB, #RRGGBB, #RRGGBBAA
• rgb() / rgba(), both comma and space syntax
• hsl() / hsla()
• Optionally named CSS colors (rebeccapurple), though this is the least valuable and the most false-positive prone

Rendering the swatch from a parsed literal is preferable to honoring model-emitted
ANSI. It keeps the sanitizer intact, avoids an escape-injection surface, and works on
output the model didn't specially format - including color codes quoted from files.

Suggested details:

• Render as a two-space background-colored block immediately before or after the literal.
• Apply inside fenced code blocks too - that's where most color codes appear.
• Degrade to no swatch when the terminal doesn't report truecolor support, rather than falling back to a wrong 256-color approximation.
• Gate behind a setting ("colorDecorators": true) if the default is controversial.

Alternative Solutions

Everything reachable from user space was tried and is inadequate:

CLAUDE.md rule instructing Claude to emit ANSI escapes. Blocked by the sanitizer.
This is the natural first attempt and it fails silently - the user sees raw escape text.

A skill. Skills only supply instructions to the model. They cannot affect rendering, so they hit exactly the same wall.

Hooks. No hook in the current set - PreToolUse, PostToolUse, UserPromptSubmit, Notification, Stop, SubagentStop, PreCompact, SessionStart, SessionEnd - can transform assistant-message text. Hooks wrap tool calls and lifecycle events, not rendering.

Shelling out to a swatch script via the Bash tool. This works, since Bash output isn't sanitized:

#!/usr/bin/env bash
for h in "$@"; do
  x=${h#\#}
  printf '\033[48;2;%d;%d;%dm  \033[0m %s\n' 0x${x:0:2} 0x${x:2:2} 0x${x:4:2} "#$x"
done

But it costs a tool call per palette, clutters the transcript, needs an allowlist
entry to avoid a permission prompt every time, and does nothing for color codes that appear incidentally mid-explanation.

Nearest-of-9 emoji squares (🟥🟧🟨🟩🟦🟪🟫⬛⬜). Free and inline, but nine buckets is far too coarse for palette work - every blue-ish color collapses to 🟦.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

Asking Claude to propose a palette for a dashboard:

Here's a six-color categorical palette: - #2E86AB - primary - #A23B72 - secondary - #F18F01 - accent - #C73E1D - danger - #3B7A57 - success - #6B705C - muted

Today this is six opaque strings. To judge whether the palette is balanced or whether two colors are too close, the user leaves the terminal.

With decorators, each line carries its own swatch and the palette is reviewable in
place - which matters most precisely when there are several colors and their relationship to each other is the thing being evaluated.

Same applies to reading existing code: grep a theme file, and the results are readable as colors rather than as hex strings.

Additional Context

Environment: Claude Code CLI, macOS (Darwin 25.5.0), zsh, terminal (iTerm2) with verified 24-bit color support.

Verification that the terminal and transport are not the limitation - run through the Bash tool, renders correctly:

printf '\033[48;2;255;107;53m \033[0m #FF6B35\n'

The same sequence in an assistant message doesn't.

Prior art: VS Code color decorators, the colorize and Color Highlight extensions, and bat's syntax-aware highlighting all solve the equivalent problem by parsing the literal rather than trusting embedded escapes.