Windows 0.148+: light-theme composer is near-black (OSC 10/11 probe dropped; still broken in 0.150.1)

What version of Codex CLI is running?

codex-cli 0.150.1 (regression vs 0.147.0; every release after 0.147 that I have tried is affected)

What subscription do you have?

Plus

Which model were you using?

gpt-5.6-sol (TUI rendering only; not model-specific)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

Windows Terminal 1.24.11911.0, PowerShell 7.6.5, no multiplexer. WT_SESSION is set.

Codex doctor report

not attached (local paths / plugin config). Happy to provide a redacted codex doctor --json if useful.

What issue are you seeing?

In a light Windows Terminal theme, the rest of the TUI is readable, but the conversation composer / input box is painted a solid near-black bar. Placeholder text (Ask Codex to do anything) and typed text keep the terminal's default dark foreground, so the input is nearly unreadable.

This is not a live theme-switch glitch. It happens immediately on a fresh codex start.

0.147.0 is fine in the same terminal / profile. Every later CLI I have tried (0.148.0 through 0.150.1) shows the dark composer.

tui.theme (I use "github") does not change this; it only affects syntax highlighting.

What steps can reproduce the bug?

1. Use Windows Terminal with a light color scheme (light background, dark default foreground). Leave the ConPTY 16-color table at the usual Campbell-style defaults (background index 0 ≈ #0C0C0C).
2. Install Codex CLI 0.150.1 (npm i -g @openai/codex@0.150.1).
3. Run codex from PowerShell in that tab.
4. Observe the composer: dark fill, dark placeholder/text.
5. Downgrade to 0.147.0 in the same tab / profile: composer tint matches the visible light background.

What is the expected behavior?

Composer (and user-message pills, which share user_message_style()) should follow the visible terminal default background, as 0.147 did when OSC 10/11 succeeded. Header/transcript already look correct because they do not paint a probed RGB fill.

Additional information

Related issues

This is the same 0.148 Windows regression as:

• #39418 (closed as completed on 2026-08-25; the referenced restore-OSC commit is on a fork, not in rust-v0.150.1)
• #37769 (open; WT_SESSION truecolor promotion + untrustworthy Win32 background)

Filing this because stable 0.150.1 still has the broken Windows probe, so the closed issue did not ship a fix to npm.

Root cause (from comparing rust-v0.147.0 vs rust-v0.150.1)

Composer fill comes from user_message_style() → default_bg() → user_message_bg():

• If the probed background is classified light: blend(black, bg, 0.04) (subtle).
• If classified dark: blend(white, bg, 0.12) (near-black when bg is #0C0C0C).
• Text/placeholder stay Style::default() / dim, i.e. the terminal default dark foreground.

0.147 Windows (codex-rs/tui/src/terminal_probe.rs): OSC 10/11 first, GetConsoleScreenBufferInfoEx only as fallback. Windows Terminal answers OSC 11 with the scheme RGB, so the composer matches what the user sees.

0.148+ Windows (still in 0.150.1): OSC was removed so startup typeahead is not consumed from the console input queue (#38641). Windows now only reads ConPTY:

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

On Windows Terminal, that 16-color table is not the profile theme. Default background lives in WT's extra slots (~261/262). wAttributes typically stays 0x0007 (fg index 7, bg index 0 → #0C0C0C). Codex then:

1. Treats the terminal as dark (is_light luma ≤ 128).
2. Because WT_SESSION promotes the color level to TrueColor, paints an explicit Color::Rgb composer fill ≈ #1F1F1F.
3. Leaves input text on the real light-theme default foreground → dark-on-dark.

style.rs is unchanged across 0.147 → 0.150.1. The regression is background acquisition, not the blend math.

Current main delays the Windows probe (probe_default_colors_after_protected_startup) so OSC replies cannot be mistaken for trust-screen input, but it still calls the same GetConsoleScreenBufferInfoEx-only default_colors().

Suggested fix

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

• Run the bounded OSC query in a window that owns stdin (startup probe / after protected screens, with replay of leftover bytes as the Unix probe already does), or
• Prefer OSC when a reply arrives within the existing 100ms budget, then fall back to GetConsoleScreenBufferInfoEx.

Alternatively, when running under Windows Terminal and the only source is the legacy Win32 table, do not treat that RGB as authoritative for large painted regions: return None from user_message_style_for so the composer inherits Color::Reset instead of painting #1F1F1F. Keep WT_SESSION truecolor promotion for syntax/diffs.

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.

Workaround (does not fix Codex)

Setting PowerShell RawUI to match the visible theme before launch:

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

This changes GetConsoleScreenBufferInfoEx to a light index, so 0.148+ paints a light composer. The Windows Terminal profile itself is unchanged. Pinning to 0.147.0 also avoids the bug.

Start in codex-rs/tui/src/terminal_probe.rs at default_colors() and probe_default_colors_after_protected_startup(), then inspect style.rs at user_message_style() and user_message_bg(). Reproduce on Windows Terminal with a light theme and compare against 0.147.0. Done means the composer and user-message pills follow the visible light background while startup typeahead remains safe and non-OSC hosts retain a fallback.