Diff rendering (still) looks bad on Apple Terminal.app on Monterey
What version of Codex CLI is running?
0.116.0
What subscription do you have?
N/A
Which model were you using?
N/A
What platform is your computer?
macOS Monterey v12.7.6
What terminal emulator and version are you using (if applicable)?
Terminal.app (Version 2.12.7 (445.1))
What issue are you seeing?
I'm getting the same "green-on-green" diff rendering issue previously described in such issues as #12749, #12904. This version of Terminal.app does not support "true color", only ANSI/xterm indexed colors. It sets TERM to xterm-256color and TERM_PROGRAM to Apple_Terminal, and it does not set COLORTERM.
Setting NO_COLOR does work to disable all diff coloring, which at least restores a little bit of legibility, though it also disables the background of the input field. Setting FORCE_COLOR=1 is also a bit of a workaround, although it too disables the input field background, and the foreground color of the diff lines is dim green, not bright green.
Attaching screenshot of the main problem without any workarounds in place. For a terminal emulator without "true color" support, I'd expect Codex to still render as good a UI as it can with the available color palette (in this case, the xterm palette).
What steps can reproduce the bug?
Launch codex, and direct the LLM to apply some diff to a file. Witness the rendering of the diff.
What is the expected behavior?
It should be legible.
Additional information
<img width="774" height="672" alt="Image" src="https://github.com/user-attachments/assets/2ab30d45-7bde-4690-b19d-b767ea204517" />
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Incidentally, the same text in the theme picker is more legible!
<img width="774" height="897" alt="Image" src="https://github.com/user-attachments/assets/28daed2a-ee3a-4343-8607-f603c5c8af12" />
Oh, it's even more bizarre. When I first bring up the theme picker, it looks just as bad:
<img width="774" height="672" alt="Image" src="https://github.com/user-attachments/assets/2670dd6d-360c-4992-ab61-10c9f5754370" />
If I then move up and then back down the theme list, it corrects itself:
<img width="774" height="672" alt="Image" src="https://github.com/user-attachments/assets/afb594e5-5fa7-4227-af4c-09801a0898aa" />
Resizing the window causes the theme picker to look bad again.
OK, after poking at my Terminal.app a bit, I think that (part of) the problem is that it does not ignore 24-bit "true color" commands. Instead, a command like:
is interpreted as:
38 ;-> expecting5 ;to pick an xterm foreground color2 ;-> not5 ;, so instead it interprets this as "faint text"255 ; 255 ; 255-> unrecognized; ignoredwhich explains why we end up with faint white text over the green background.
Ultimately, the core problem is still that Codex is trying to use "true color" on a terminal emulator that does not declare support for it.
Same issue with unreadable highlighted green text on the ChromeOS Terminal app. Frustrating to see variations of this same issue going back 1 yr+ that keep being closed as "fixed". Why couldn't we just disable the highlighted background entirely on any themes? They all have the same issue currently...
FWIW, @ekwoodrich, I worked around this in the macOS terminal emulator using this script, which rewrites the terminal "true color" sequences to older xterm color sequences. I don't know if the same workaround would work for ChromeOS's terminal emulator, but I'd be interested to know your results if you decide to try it.
https://github.com/mhjacobson/filter-truecolor/blob/master/filter-truecolor.py