Color diff in Warp terminal is unreadable in the new version (Windows)

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

• ##12749
• ##12890
• ##11972

Powered by Codex Action

try /theme

just tried all the themes that are built into Codex CLI. Some of them improve it a bit, but none are perfect, in the sense that they’re all still relatively hard to read. So the issue must be somewhere else. :(

Can confirm theme changes have no effect on background color. They change foreground color, but background stays pure green or screaming red. This was not a problem in the previous version (104?)

<img width="516" height="373" alt="Image" src="https://github.com/user-attachments/assets/a1cd9c23-7a27-431c-ab38-d422fd6b9601" />

My eyes are begging for mercy.

#12912

https://github.com/openai/codex/issues/12749#issuecomment-3965731433

This is what it looks like in the WezTerm terminal on Windows. Overall, it's not bad, but I would like the ability to customize the theme in detail, as I need and not just choosing from presets.

<img width="1411" height="935" alt="Image" src="https://github.com/user-attachments/assets/ed3788ca-9258-4e5f-959b-5cadf749604d" />

For those of you using Windows Terminal can you try running set TERM=xterm-256 first and then running codex and report if it improves? Should look more like what you see in the WezTerm example above.

Environment

• OS: Windows 10 LTSC
• Terminal: WezTerm
• Shell: Windows PowerShell 5.1
• Codex CLI: 0.105.0 (TUI diff background issue)

What I tested

I tried the suggested workaround of forcing 256-color terminfo, and also tested what happens when I remove truecolor signaling.

Case A (baseline, less “toxic” background)

Start Codex normally in WezTerm / PowerShell 5.1. In my case the environment contained:

• TERM=xterm-256 (when set for the session)
• COLORTERM=truecolor

In this mode the diff background blocks were still present, but the green/red looked noticeably darker and more readable (see Screenshot A).

Case B (forced “no truecolor”, background becomes more “toxic”)

I restarted Codex with TERM=xterm-256 and explicitly removed COLORTERM before launching Codex. Then I ran a minimal probe via Codex harness to capture the effective environment seen by both cmd.exe and PowerShell (absolute path).

Probe output (raw):

=== CMD ENV ===
TERM=xterm-256
COLORTERM=
WT_SESSION=
=== POWERSHELL ENV (full path) ===
PS_TERM=xterm-256
PS_COLORTERM=
PS_WT_SESSION=

In this mode the same TUI diff background rendering became much more “toxic” (pure bright green / bright red fills), making diffs harder to read (see Screenshot B).

Conclusion / Why this matters

• TERM=xterm-256 is successfully propagated into the Codex Windows harness (cmd.exe) and into PowerShell when invoked by absolute path.
• Removing COLORTERM=truecolor changes Codex’s background coloring behavior, but does not fix the underlying issue. It actually makes backgrounds more aggressive in my setup.
• This suggests the problem is in Codex TUI’s diff background color selection / theming (and how it chooses between truecolor vs 256-color paths), not in the terminal theme itself.

(Attached: Screenshot A = less toxic, Screenshot B = more toxic.)

<img width="1538" height="798" alt="Image" src="https://github.com/user-attachments/assets/54d2c5b4-a3e5-478d-acbd-01eda41208b2" />

<img width="1548" height="799" alt="Image" src="https://github.com/user-attachments/assets/afba0705-7721-4873-8553-f089059cf30a" />

Dup of #12749

As mentioned in #12749, I implemented a fix in https://github.com/ignatremizov/codex/pull/1 but cannot open a PR here

Thanks to @tagor-sian for the guidance. The root cause of this UI glitch is that the application lacks proper "color fallback" adaptation. Here is the technical breakdown:

The Technical Reality: Truecolor vs. ANSI 16

• Truecolor (24-bit): Supports 16 million colors, allowing for the subtle, soft "dark red/green" backgrounds intended by the developers.
• ANSI 16-color: A legacy standard with a very limited palette of high-saturation, high-brightness colors (the "flashbang" colors we are seeing).

The Developer's Blind Spot

The Codex developers likely work on modern terminals (macOS or optimized Linux environments) where Truecolor is the default. The "soft dark highlights" they chose look great in those environments, so the code was pushed as-is.

The Windows/Environment Issue

On many Windows systems (or environments where COLORTERM isn't explicitly set), the underlying UI library assumes the terminal is legacy and doesn't support Truecolor. To be "safe," it automatically downgrades the colors.

The Disaster (Forced Mapping)

Since the library is forced to use the 16-color palette, it performs a crude "forced mapping." It maps the developer's sophisticated, soft shades to the nearest available basic colors—which happen to be the eye-searing, neon-bright "Red" and "Green."

---

Temporary Workaround for Users

If you are using PowerShell, you can manually force Truecolor support by running the following command before launching Codex:

$env:COLORTERM="truecolor"

This should restore the intended soft color scheme. Hopefully, the developers can implement a fix to handle this fallback more gracefully!

Thanks to @tagor-sian for the guidance. The root cause of this UI glitch is that the application lacks proper "color fallback" adaptation. Here is the technical breakdown: #### The Technical Reality: Truecolor vs. ANSI 16 Truecolor (24-bit): Supports 16 million colors, allowing for the subtle, soft "dark red/green" backgrounds intended by the developers. ANSI 16-color: A legacy standard with a very limited palette of high-saturation, high-brightness colors (the "flashbang" colors we are seeing). #### The Developer's Blind Spot The Codex developers likely work on modern terminals (macOS or optimized Linux environments) where Truecolor is the default. The "soft dark highlights" they chose look great in those environments, so the code was pushed as-is. #### The Windows/Environment Issue On many Windows systems (or environments where COLORTERM isn't explicitly set), the underlying UI library assumes the terminal is legacy and doesn't support Truecolor. To be "safe," it automatically downgrades the colors. #### The Disaster (Forced Mapping) Since the library is forced to use the 16-color palette, it performs a crude "forced mapping." It maps the developer's sophisticated, soft shades to the nearest available basic colors—which happen to be the eye-searing, neon-bright "Red" and "Green." --- #### Temporary Workaround for Users If you are using PowerShell, you can manually force Truecolor support by running the following command before launching Codex: ``powershell $env:COLORTERM="truecolor" `` This should restore the intended soft color scheme. Hopefully, the developers can implement a fix to handle this fallback more gracefully!

this works

I found this. _https://github.com/aofp/yume_
Helps a little so you can read the diff without suffering from the stupid background until an update is released.