Colour-coded Claude responses

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

In Claude Code, all assistant output renders as the same white monospace text regardless of its purpose. During a session, the assistant produces several distinct types of output: reasoning through a problem, directly answering a user’s question, asking the user a question, and providing status updates on running tasks. When messages stack up quickly (especially when the user queues multiple commands), it becomes difficult to scan the conversation and distinguish what requires attention from what is informational. The user has to read every line to figure out if something is a question directed at them, an answer they asked for, or just the assistant thinking out loud.

Proposed Solution

Color-code (or otherwise visually differentiate) the assistant’s text output by intent category. For example:
• Answers to user questions - one color (the primary response the user is waiting for)
• Questions directed at the user - a distinct color or indicator (requires user input to proceed)
• Status updates / progress notes - a muted or secondary color (informational, no action needed)
• Analysis / reasoning - another treatment (context for the decision, but not the decision itself)
This could be implemented as colored text, background highlights, left-border accents, or prefix icons. The goal is that a user glancing at a long scrollback can instantly spot “where is the assistant asking me something” or “where is the answer to what I asked” without reading every line.

Alternative Solutions

1. AskUserQuestion tool - When I need input from you, I can use the structured question UI (the clickable option cards) instead of asking in plain text. That gives questions a visually distinct treatment. I can default to this more often.
2. Markdown formatting - I can adopt conventions like always bolding direct answers, using > blockquotes for reasoning, and using headers to label sections. But this is self-discipline, not enforced, and it adds visual noise.
3. Shorter responses - If I keep each message to one purpose (just the answer, just the question, just the status update), there’s less to differentiate. But that conflicts with efficiency when you’re stacking commands.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

The user is building an iOS app with Claude Code. They paste a screenshot of an Xcode build error and type “fix this.” While Claude is working on that, they also type “and remind me what API endpoint the scene voting uses.”
Claude responds with a single block of white text:
Current experience (all white text):
Looking at the error, it seems like TierExplainerView isn’t being found in scope. This usually means the file isn’t added to Compile Sources in the Xcode project. Let me check if the file exists on disk. The file exists at ios/FilmScout/Views/ScoutScore/TierExplainerView.swift but your Xcode project doesn’t have it in Compile Sources. You need to add it manually since I can’t edit the .xcodeproj from this environment. Should I also check if any other new files are missing from Compile Sources, or just this one? The scene voting endpoint is POST /api/scenes/vote with a JSON body containing movie_id, scene_id, vote_type, and an optional reason field.
The user has to read the entire block to find three different things: the diagnosis, a question waiting for their answer, and the API info they asked about. If they’re glancing at their phone while walking, they might miss the question entirely and Claude sits idle waiting.
Proposed experience (color-coded):
[GRAY - reasoning/context] Looking at the error, TierExplainerView isn’t found in scope. The file exists on disk but isn’t in Xcode’s Compile Sources. I can’t edit .xcodeproj from this environment, so you’ll need to add it manually.
[WHITE/BOLD - direct answer] The scene voting endpoint is POST /api/scenes/vote with a JSON body containing movie_id, scene_id, vote_type, and an optional reason field.
[CYAN - question needing user input] Should I also check if any other new files are missing from Compile Sources, or just this one?
The user can instantly see: gray is context/reasoning (skip if busy), white/bold is the direct answer they asked for, and cyan is a question that needs their input before Claude can continue.

Additional Context

_No response_