Improve user message contrast in the CLI TUI

Open 💬 2 comments Opened Mar 25, 2026 by de-monkey-v

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI

What feature would you like to see?

User messages in the CLI TUI can be hard to distinguish from Codex responses when the terminal theme renders both with nearly the same foreground and background colors.

A small but high-impact improvement would be to render user messages with a stronger background panel so they remain easy to visually scan in the transcript.

A good default would be:

strengthen the user-message background blend when the terminal background is known
use an explicit gray fallback panel when terminal background detection is unavailable
apply the same behavior in both codex-rs/tui and codex-rs/tui_app_server

This is narrower than full theme customization, but it materially improves readability immediately.

Additional information

This seems related to #2020, but it is a more targeted usability fix that does not require a full light/dark theme system.

I have a working branch with the change here:

de-monkey-v:gyu/tui-user-message-contrast

The branch updates:

codex-rs/tui/src/style.rs
codex-rs/tui_app_server/src/style.rs
related TUI snapshots

Local validation for that branch:

just fmt
cargo test -p codex-tui --lib
cargo test -p codex-tui-app-server --lib
./tools/argument-comment-lint/run.sh

If useful, I can also turn that branch into a patch or follow any preferred contribution path for repos with collaborator-only PR creation.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#14996
#14797

Powered by Codex Action

0xble · 4 months ago

I implemented this in a fork, and it helped with exactly the readability problem described here.

The two changes that made the difference were:

when terminal background detection is unavailable, don't fall back to no panel background; use a stable shaded fallback surface instead
when COLORFGBG is available, use it only to decide dark vs light fallback, not as the exact panel RGB

Using the raw queried RGB directly still looked wrong under mosh and some remote-terminal paths. Using it only as a theme classifier got the panel colors much closer to normal Codex rendering.

Fork-local reference:

This still feels a lot narrower than full theming. It's basically just making shaded user/composer surfaces degrade predictably when palette detection is partial or missing.