[Bug] Windows 0.148 composer colors ignore terminal theme after dropping OSC 10/11

What version of Codex CLI is running?

0.148.0 (regression vs 0.147.x)

What subscription do you have?

n/a (host-terminal integration report)

Which model were you using?

n/a (TUI rendering only)

What platform is your computer?

Windows 11 x64 (PowerShell 7). Also affects other Windows hosts that use ConPTY + an xterm.js renderer (VS Code, custom Electron terminals).

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

Any Windows terminal whose visible theme is not the ConPTY 16-color table:

• Windows Terminal with a light scheme
• VS Code / Cursor integrated terminal
• Electron xterm.js hosts such as Netcatty

Codex doctor report

not available (root-cause report from source; original user screenshot is in binaricat/Netcatty#3066)

What issue are you seeing?

On Windows, Codex 0.148.0 paints the composer with inverted / unreadable colors whenever the visible terminal theme disagrees with ConPTY's default palette.

Typical light terminal:

• Header / transcript use the terminal default background and look correct
• Composer is a solid near-black bar
• Placeholder text uses the terminal default (dark) foreground → black on black

Typical dark terminal with a light ConPTY table, or a dark xterm.js theme whose default fg is light while the composer fill is computed from ConPTY: poor contrast, “bright box, unreadable text”.

0.147.x in the same terminal is fine.

What steps can reproduce the bug?

1. Use a Windows host where rendering is xterm.js (or Windows Terminal with a light scheme) and PTY is ConPTY.
2. Set a light terminal theme (light bg, dark fg). Leave ConPTY's default Campbell table untouched (bg index 0 ≈ #0C0C0C).
3. Run codex 0.148.0.
4. Observe the composer fill vs the rest of the TUI.
5. Repeat with 0.147.x in the same terminal: composer tint matches the visible theme.

What is the expected behavior?

Composer shading should follow the visible terminal default background (OSC 11 / equivalent), as 0.147 did on terminals that answer OSC 10/11. Header already does this because it does not paint a probed RGB fill.

Additional information

Root cause

user_message_style() tints the composer from default_bg(). On truecolor (COLORTERM=truecolor, or WT_SESSION → StdoutColorLevel::TrueColor) that fill is a real Color::Rgb.

0.147 Windows (terminal_probe.rs): probe OSC 10/11 first, then fall back to GetConsoleScreenBufferInfoEx.

write_all(output, b"\x1B]10;?\x1B\\\x1B]11;?\x1B\\")?;
// if parsed → use those colors
// else → GetConsoleScreenBufferInfoEx ColorTable

xterm.js / Windows Terminal answer OSC 11 with the theme background, so the composer matches what the user sees.

0.148 Windows: OSC was removed so startup typeahead is not consumed from the console input queue. Windows now only reads ConPTY:

GetStdHandle(STD_OUTPUT_HANDLE)
GetConsoleScreenBufferInfoEx → ColorTable[fg/bg from wAttributes]

ConPTY's ColorTable is the default Windows console palette (typically wAttributes = 0x0007, bg #0C0C0C, fg #CCCCCC). It is not the emulator theme. Codex then treats the terminal as dark and paints blend((255,255,255), (12,12,12), 0.12) ≈ #1f1f1f as a truecolor composer fill.

This was independently measured in #37769: the same GetConsoleScreenBufferInfoEx values for Windows Terminal vs conhost, while the visible WT scheme differs. #37769 is about WT_SESSION promoting truecolor; 0.148 makes the same mismatch the only Windows path, including hosts that never set WT_SESSION.

#26181 originally added the Windows OSC 10/11 probe specifically so the composer could follow the real terminal background. 0.148 reverted that path.

Suggested fix

Restore a Windows OSC 10/11 probe for terminals that reply, without dropping typeahead:

• Keep the 0.147 bounded OSC query, but run it before the composer owns the input queue (same window as the rest of the startup probe), or
• Parse OSC replies without consuming unrelated input (replay leftover bytes, as the Unix startup probe already does), or
• Prefer OSC when a reply arrives within the existing 100ms budget, and only then fall back to GetConsoleScreenBufferInfoEx.

GetConsoleScreenBufferInfoEx is a reasonable fallback for hosts that do not speak OSC; it should not be the sole source when the renderer theme lives outside ConPTY.

Related: #8852 (older “no tint on Windows”), #37769 (WT_SESSION / truecolor + dark ColorTable), #26181 (OSC 10/11 on Windows).

$Host.UI.RawUI.ForegroundColor = 'Black'
$Host.UI.RawUI.BackgroundColor = 'White'
Clear-Host
codex