[FEATURE] Content-type color coding for assistant output (questions, commands, narrative)
Feature Request
Configurable color coding for different types of assistant output in the terminal.
Currently, Claude Code's terminal output uses a uniform color for all assistant text. The only visual differentiation comes from tool call borders and markdown code blocks. This makes it hard to quickly scan output and distinguish between:
- Questions / feedback requests — when Claude asks the user something
- Commands / tool calls — what Claude is executing
- Narrative / explanation — context and reasoning
- Warnings / important notices — things requiring attention
- Status updates — progress indicators
Problem
In long conversations or multi-step workflows, users must read every line to find the actionable parts. Questions get buried in explanation. Commands blend with narrative. This slows down the feedback loop, especially for power users running in auto mode who need to quickly spot when Claude is asking for input vs. reporting progress.
Proposed Solution
Add a configurable color mapping in settings.json (or via /config) that lets users assign terminal colors to content types:
// Example — exact schema up to the team
{
"theme": {
"contentColors": {
"question": "yellow",
"command": "cyan",
"warning": "red",
"status": "dim",
"narrative": "default"
}
}
}
Classification could use lightweight heuristics (lines ending in ?, lines starting with >, tool call summaries, etc.) — doesn't need to be perfect to be useful.
Alternatives Considered
- Terminal emulator regex triggers (iTerm2 supports this, but platform-specific and fragile)
- Custom hooks that post-process output (no access to the output stream)
- Markdown heading conventions (helps structure, but no color differentiation)
Additional Context
- The existing
/themesetting only switches the overall palette (light/dark/daltonized) — this would be orthogonal - Related but distinct from #48636 (syntax highlighting in code blocks) and #34582 (agent name colors in multi-agent view)
- Would significantly improve accessibility for users who scan output visually rather than reading linearly
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗