/color command: support arbitrary hex colors (terminals already support truecolor)

Status Closed — not planned
Maintainer reply None cached
Activity 5 comments · opened Jul 5, 2026 · closed Sep 20, 2026

Summary

The /color command currently accepts only 8 named colors: red, blue, green, yellow, purple, orange, pink, cyan, default. Modern terminals (VS Code integrated terminal, iTerm2, Ghostty, Kitty, WezTerm, Alacritty) all support 24-bit true color via COLORTERM=truecolor. The named-color limitation is a CLI UI decision, not a terminal constraint.

Use case

In multi-agent projects where multiple Claude Code sessions collaborate on the same repo, each session gets a persistent identity — a name and a color stored in a project config file. The hex color is the canonical identifier used in documentation, rendered surfaces, and session provenance tracking.

The current 8-color palette forces lossy quantization: two sessions whose canonical colors are #B45309 (amber) and #78716C (warm stone gray) both map to orange, producing a collision that defeats the purpose of per-session color identity.

Proposed change

Accept hex colors in /color:

/color #78716C

Detection: if the argument starts with # and is a valid 6-digit hex color, use 24-bit ANSI escape sequences (\033[38;2;R;G;Bm) to render it. Named colors continue to work unchanged.

Graceful degradation: if COLORTERM is not truecolor or 24bit, fall back to nearest named color (existing behavior) and optionally warn: Terminal does not support truecolor; using nearest approximation: orange.

Implementation sketch

if (arg.startsWith('#') && /^#[0-9a-f]{6}$/i.test(arg)) {
  const r = parseInt(arg.slice(1,3), 16)
  const g = parseInt(arg.slice(3,5), 16)
  const b = parseInt(arg.slice(5,7), 16)
  if (process.env.COLORTERM === 'truecolor' || process.env.COLORTERM === '24bit') {
    setSessionColor(`\x1b[38;2;${r};${g};${b}m`)
  } else {
    setSessionColor(nearestNamedColor(r, g, b)) // existing fallback
  }
}

Expected behavior after fix

/color #78716C     → session renders in warm stone gray  
/color orange      → unchanged, still works
/color #xyz        → error: "Invalid hex color"

Environment

  • macOS, VS Code integrated terminal + iTerm2
  • COLORTERM=truecolor confirmed in both

View original on GitHub ↗

5 Comments

DrAlexHarrison · 3 months ago

+1. Concrete use case: a multi-account, multi-repo setup that color-codes every session's prompt bar by account and repo (5 subscription accounts x 19 repos here) — 8 named slots can't span that palette, while every modern terminal renders truecolor fine. We currently maintain a local binary patch to let #hex through the /color gate and resolvers, re-anchored after CLI updates; native hex support would retire all of that. (Posted by Claude Code on behalf of the account owner.)

github-actions[bot] · 25 days ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

jlumbroso · 18 days ago

No, this shouldn't be closed. The number of colors is still 8 — while elsewhere the harness is using fancy colors for its own display.

This is a feature that Opus 5.5 or Sonnet 5 can implement in less than an hour.

You just need to believe it's important enough — and I am telling you that it is.

jlumbroso · 18 days ago

I reopened this as https://github.com/anthropics/claude-code/issues/97652

You can implement or keep it on the books, but don't close it as stale.

DrAlexHarrison · 18 days ago

I still really want this, too.