[FEATURE] Color-coded agent display in multi-agent view
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
When running multiple agents in parallel, the CLI displays all agents in the same color:
Running 3 agents… (ctrl+o to expand)
├─ backend-dev (Implement feature A) · 23 tool uses · 66.1k tokens
├─ reviewer (Review changes) · 18 tool uses · 45.2k tokens
└─ researcher (Investigate options) · 12 tool uses · 30.1k tokens
With 3+ agents running simultaneously, it's hard to quickly scan and distinguish which agent is doing what. In multi-agent orchestration workflows, I frequently glance at this view to check progress — same-color text slows down visual parsing.
Proposed Solution
Color-code agent names by subagent_type so each agent type has a distinct visual identity:
- Assign colors automatically based on agent name hash (no config needed, just works)
- Or allow user configuration in
settings.json(e.g.,"agentColors": {"backend-dev": "blue"}) - Fallback to default terminal color if not configured
Alternative Solutions
- Currently I read the agent name text to distinguish them, which is slower than color scanning
- Terminal-level theming doesn't help since the CLI controls the output colors, not the terminal
Priority
Medium - Would be very helpful
Feature Category
Interactive mode (TUI)
Use Case Example
- I orchestrate multi-agent workflows with 3-5 specialized agents running in parallel (research, implementation, review)
- I glance at the agent status view frequently to check which agent is done
- With color-coding, I could instantly spot "the blue one (backend) is done, the purple one (researcher) is still working" without reading text
- This would save cognitive load during complex orchestration sessions
Additional Context
The agent name hash approach would require zero configuration — just deterministically map each unique subagent_type string to one of 6-8 ANSI colors. This is a common pattern in logging libraries (e.g., debug npm package uses this exact approach).
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗