Feature: Role-based color differentiation (user / agent / sub-backend / tools)
Problem
Currently, all messages in the TUI are rendered in a single color scheme.
When the user works with multiple backends (DeepSeek API, OpenClaw CLI,
Hermes, etc.) or sub-agents, it's hard to visually distinguish:
- User input vs DeepSeek agent response
- DeepSeek main response vs sub-backend output (OpenClaw / Hermes)
- Tool execution results (shell output)
This is friction in "TUI as multi-backend control panel" workflows.
Proposed solution
Add a [display.colors] section to config.toml with role-based ANSI color
mappings:
[display.colors]
user = "93" # bright yellow
agent = "36" # cyan
tool_output = "33" # gold
subagent = "35" # magenta (for sub-agents / delegated calls)
backend_openclaw = "35"
backend_hermes = "214"
Or more general:
[display.roles]
user = { fg = "bright yellow" }
agent = { fg = "cyan" }
tool = { fg = "yellow" }
subagent = { fg = "magenta" }
Use case
The user described their setup as:
"TUI is the central console connecting multiple backends —
DeepSeek as the main reasoning engine, OpenClaw via CLI for
tool execution (music generation, browser), Hermes for memory
persistence."
With color-coded backend sources, the user can see at a glance
which system produced which output.
Existing references
Acceptance criteria
config.toml supports per-role fg/bg ANSI 256-color values
- Falls back to current defaults if not configured
- Works across terminal emulators supporting 256-color or true color
- Future-proof: adding a backend only requires an additional color key
Feature: Role-based color differentiation (user / agent / sub-backend / tools)
Problem
Currently, all messages in the TUI are rendered in a single color scheme.
When the user works with multiple backends (DeepSeek API, OpenClaw CLI,
Hermes, etc.) or sub-agents, it's hard to visually distinguish:
This is friction in "TUI as multi-backend control panel" workflows.
Proposed solution
Add a
[display.colors]section toconfig.tomlwith role-based ANSI colormappings:
Or more general:
Use case
The user described their setup as:
With color-coded backend sources, the user can see at a glance
which system produced which output.
Existing references
(bat --theme, delta --syntax-theme, etc.)
Acceptance criteria
config.tomlsupports per-role fg/bg ANSI 256-color values