`ansi` theme is rendered as explicit RGB colors instead of terminal ANSI palette indices

Resolved 💬 7 comments Opened Feb 26, 2026 by tummetott Closed Mar 5, 2026
💡 Likely answer: A maintainer (fcoury, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.105.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Darwin 24.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Wezterm

What issue are you seeing?

Continuation of #1618

When tui.theme = "ansi" is selected, the displayed syntax colors do not follow the terminal’s configured ANSI palette. The current behavior appears to render syntax highlighting with explicit RGB values, which bypasses ANSI index mapping in the terminal.

So in other words: the ansi theme is just another bundled theme that hardcodes random colors instead of using the ANSI-indexed terminal-palette

Relevant code paths suggest this behavior is intentional in current implementation:

codex-rs/tui/src/render/highlight.rs:125: maps ansi to EmbeddedThemeName::Ansi
codex-rs/tui/src/render/highlight.rs:380: applies syntax fg as RtColor::Rgb(fg.r, fg.g, fg.b)
codex-rs/tui/src/render/highlight.rs:371: comments that syntax themes produce RGB colors

What steps can reproduce the bug?

  1. Configure a terminal with clearly customized ANSI palette colors.
  2. Set Codex config to:
[tui]
theme = "ansi"
  1. Open Codex TUI and view syntax-highlighted code content.
  2. Compare token colors against terminal ANSI palette slots.

What is the expected behavior?

When using the ansi theme, codex should actually use the terminals ansi palette and don't hardcode some random RGB color for syntax highlighting

Additional information

_No response_

View original on GitHub ↗

7 Comments

tummetott · 4 months ago

Same story applies to base16 and base16-256. They simply do not pick up the terminal colors

thesofakillers · 4 months ago

can confirm. result of this is that e.g. the diff colors are off. e.g. here's codex's gruvbox light inside a iterm2 gruvbox-light colored terminal, using some off-theme pink and blue rather gruvbox's red and green.

<img width="968" height="180" alt="Image" src="https://github.com/user-attachments/assets/96425d9f-eaa6-449d-957b-695d35d31b3e" />

the pink and blue seems to apply for all color themes to varying extents

tummetott · 4 months ago
can confirm. result of this is that e.g. the diff colors are off. e.g. here's codex's gruvbox light inside a iterm2 gruvbox-light colored terminal, using some off-theme pink and blue rather gruvbox's red and green.

actually this is more related to #12912

diff background colors are currently hardcoded.

On a sidenote, all built in themes except ansi, base16, and base16-256 are supposed to use bundled RGB values. They are not meant to inherit or load colors from the terminal emulator. The three exceptions mentioned above should theoretically use the terminal’s ANSI colors, just mapped to different ANSI indexes. But that’s currently not the case.

tummetott · 4 months ago

@fcoury @etraut-openai

This issue is not resolved.

The referenced PR fixed the diff background coloring, but that is unrelated to the problem described here.

The actual issue is that the ansi, base16, and base16-256 themes still do not provide proper syntax highlighting. When selecting /theme ansi, code snippets render without any syntax colors. Everything appears effectively black, regardless of the terminal’s configured ANSI palette.

To reproduce:

  1. Configure your terminal with a clearly customized ANSI color palette.
  2. Start Codex.
  3. Select /theme ansi.
  4. Trigger a code modification so highlighted code is shown.

Result:
No syntax highlighting is applied.

This issue is specifically about the expectation that ansi, base16, and base16-256 should use the terminal’s ANSI color slots for syntax highlighting. Currently, they do not appear to map syntax tokens to ANSI indexes at all.

The diff background fix does not address this behavior.

fcoury contributor · 4 months ago

Hi @tummetott, you're right — sorry for the confusion with the previous close.

The ansi, base16, and base16-256 themes use a special encoding convention in their tmTheme definitions where the alpha channel signals how to interpret the color:

  • a == 0x00 → the r byte is an ANSI palette index (0–7 or 0–255), not an RGB value
  • a == 0x01 → use the terminal's default fg/bg color

__bat__ handles this in its to_ansi_color() function, which emits proper ANSI escape codes (e.g. \x1b[32m for green) instead of RGB. Our renderer currently treats all colors as RGB (RtColor::Rgb(fg.r, fg.g, fg.b)), which is why these themes don't work as expected.

The fix is to check the alpha channel and emit indexed ANSI colors instead of RGB when appropriate. I'll look into this.

fcoury contributor · 4 months ago

Hey @tummetott, this has been implemented in v0.110.0.

Thank you for the detailed bug report and for patiently clarifying the issue!

Could you test it out and close the issue if you're satisfied with the fix?

tummetott · 4 months ago

Hello @fcoury
yes now it works as expected. thank you very much!