feat(web): visually distinguish the user's own sent messages in the session terminal (per-role message color)

[cuprecupre]

Summary

Add an opt-in way for Agent Orchestrator to visually distinguish the messages the user sends from the agent's output inside the session terminal — e.g. render my own turns in a distinct foreground color — independent of the underlying agent CLI's theme.

Motivation / problem

When following a long session in the AO terminal pane, there is no visual boundary between what I typed and what the agent produced. Both render with the same styling, so scanning back through a conversation to find "where did I ask X" is slow.

The only lever today for per-turn color is the agent CLI's own TUI theme (e.g. Codex /theme, Claude Code theme), which is not a substitute:

• It colors everything (syntax highlighting, tool output, diffs), not just my turns — I can't opt into "highlight only my messages".
• It is agent-specific and inconsistent across the different CLIs AO supports (Codex, Claude Code, Cursor, Aider, OpenCode…).
• It emits truecolor (24-bit) ANSI baked into the PTY stream, so it is not something AO can retarget from its own terminal theme.

So the differentiation I want is not achievable via agent config — it needs to live in AO.

Current behavior

• AO renders the agent inside a tmux + xterm.js pane fed by the agent's PTY.
• Messages I send (dashboard message input / ao send) are injected into the agent's pane and echoed back by the agent, so from xterm's perspective my message is indistinguishable from agent output — same default foreground.
• Result: no visual separation between my turns and the agent's.

Why AO is the right layer

AO already owns the user's message string at send time (the input box / ao send payload) and the moment of injection. That is exactly the signal needed to mark a user turn: the agent's raw PTY stream carries no reliable, cross-agent "this is the user" marker, but AO's send path does.

Proposal

Provide an opt-in setting to style the user's own turns distinctly in the session terminal. Implementation open; some options:

1. App-side turn tagging — at send time AO knows the exact submitted text; tag the corresponding echoed region so xterm renders it with a configurable foreground color (or a left gutter bar / prefix glyph).
2. Chat-log overlay — render user turns as distinct styled blocks layered over the terminal (closer to a chat transcript), leaving agent output untouched.
3. Minimal — a single configurable "user message color" in Settings › Appearance, applied to detected user turns.

Color configurable in Settings › Appearance, subtle default, with an on/off toggle so users who prefer the raw terminal keep it.

Acceptance criteria

• A setting exists to enable/disable distinct styling for the user's own messages.
• When enabled, messages I send render visually distinct (color / gutter / prefix) from agent output in the live session terminal (and, ideally, in restored/scrollback history).
• Behavior is independent of the agent's own theme and works across supported agent CLIs, degrading gracefully where turn boundaries can't be detected.
• Agent output styling (ANSI / syntax colors) is unchanged.

Related

• Colors dont show up in App similar to terminal, #2529 — "colors don't show up in App similar to terminal": about ANSI fidelity of agent output; this request is the inverse — AO adding its own styling to user turns, not faithfully rendering agent ANSI.
• The ao's claude cli's colors don't match with the colors when claude cli is spawned independently outside of ao #642, bug(web): terminal in session details page renders all output as white, losing ANSI colors #1513 / bug(web): terminal in session details page renders all output as white, losing ANSI colors #1512 — same theme of agent-color fidelity, not user-turn styling.

[i-trytoohard]

Triage: P3 — Feature (UX enhancement)

Severity: P3. Pure readability improvement — nothing is broken functionally, but it's a real ergonomic win for long sessions. Well-scoped, well-researched request (nice job distinguishing this from #2529 / #642 / #1513, which are about ANSI fidelity of agent output — the inverse problem).

---

Recommended approach: app-side turn tagging (Option 1)

The core insight in the issue is correct: AO owns the user's message string at send time, so that's the only reliable, cross-agent marker. The challenge is correlating that send-time text with where it gets echoed back in the PTY stream.

Shape:

1. At send time (message input / ao send), capture the submitted text + an injection timestamp/marker.
2. Detect the echo region in the xterm.js buffer shortly after injection. Two sub-options:
   • Timestamp-correlated: match the sent text against new buffer content arriving in a small window after injection. Fragile if the agent reformats or delays the echo.
   • Marker sequence: inject a zero-width / ANSI SGR marker around the user's input before it hits the pane, then have the xterm renderer recognize and restyle it. Cleaner, but depends on the agent not stripping it.
3. xterm.js side: custom renderer addon or buffer decorator applies the configured color / left-gutter / prefix glyph to tagged regions only. Agent output ANSI/syntax colors stay untouched.
4. Settings › Appearance: on/off toggle + color picker. Default off (opt-in), subtle default color.

---

Why not the other options

• Option 2 (chat-log overlay): essentially building a parallel transcript UI on top of the terminal. Heavy, and breaks the "it's a real terminal" feel.
• Option 3 (minimal single-color): same detection problem as Option 1, just less flexible. Subset of Option 1.

---

Risks to validate before committing

• Cross-agent echo behavior varies. Codex, Claude Code, Aider, OpenCode all echo user input differently (or partially, or not at all in some modes). Turn-boundary detection will need per-harness tuning or must degrade gracefully.
• Restored / scrollback history. xterm.js buffer decorations don't persist across reconnects by default — tagging would need to be replayed from a stored turn log to survive restore.
• Performance. Scanning PTY buffer deltas on every write could get expensive in very long sessions. Needs a bounded scan window.

---

Sizing and suggested next step

Medium effort — mostly frontend (xterm.js renderer addon + Settings UI), but the send-time to buffer correlation is the tricky research piece.

Suggest a spike first to validate that the echo region can be reliably detected across at least 2–3 supported agent CLIs before committing to the full build. If detection proves too fragile cross-agent, fall back to a lighter approach (e.g., only style messages sent via the dashboard input box where AO fully controls the render path, and leave ao send / CLI-injected messages unstyled).

[somewherelostt]

Thanks for contributing to Agent Orchestrator.

This issue is being picked up by the current external contributor on-call pair:

• @illegalcall
• @Pulkit7070

If someone is already working on this, please continue as usual.
The on-call pair is added for visibility, tracking, and support, not to take over the work.
If you need help with review, direction, reproduction, or next steps, please tag @illegalcall and @Pulkit7070 here.

For faster context or live questions, you can also join the AO Discord.

Join the session here:
https://discord.gg/H6ZDcUXmq

Come by if you want to see what is being built, ask questions, or just hang around with the community.

[anmol0b]

starting this one