The latest update seems to have messed up the coloring in windows terminal

[attikov]

What issue are you seeing?

CodexT 0.149.0 has a contrast problem with light themes in Windows Terminal. Resume-list rows and the prompt input can render dark text on dark backgrounds

Selecting a light Windows Terminal color scheme alone does not fix it. Running color F0 before starting CodexT corrects the color detection.

This may indicate that CodexT reads legacy console attributes that do not initially match Windows Terminal’s visible color scheme.

current workaround:

1. Starting Windows Terminal with the light One Half Light scheme.
2. Running color F0 before CodexT starts. This sets black text on a white console background, allowing CodexT to detect light mode correctly.
3. Setting CodexT’s syntax theme to catppuccin-latte.

[Loongphy]

Thanks for the detailed report — and especially for the color F0 observation, which pinpointed the root cause.

This is a downstream manifestation of an upstream regression: openai/codex#39418. Since upstream 0.148.0, Codex no longer queries the terminal's real colors via OSC 10/11 on Windows; it only reads the legacy console attributes (GetConsoleScreenBufferInfoEx), which do not reflect the color scheme Windows Terminal actually renders. Light themes therefore get detected as dark, and surfaces like the composer input and resume-list rows render dark-on-dark. Running color F0 rewrites exactly those legacy attributes, which is why it corrected the detection.

Fixed in c3c5c0e (fix(tui): restore OSC 10/11 default-color probe on Windows): the bounded OSC 10/11 probe is restored, with the legacy attribute table kept as fallback for terminals that cannot answer OSC. Unlike the pre-0.148 implementation, any bytes drained during the probe that are not part of the OSC replies are replayed back into the console input queue, so startup typeahead is preserved.

Verified fixed on Windows Terminal with light color schemes. An official release build containing this fix will be published shortly.