Theme follows OS apps theme instead of terminal background on Windows, leaving text unreadable after a mid-session switch (still present in 1.0.89-1)

Start by locating the color-scheme detection and change-handling entry points, including startColorSchemeListener, the OSC 11 probe, and the theme() path described in the issue. Reproduce the Windows Terminal mid-session switch, then verify that the selected palette follows the terminal background and remains readable after a theme notification or retry.

Describe the bug

On Windows, Copilot CLI decides light vs. dark from the OS apps theme, not from the terminal's actual background. When the OS theme flips mid-session (e.g. via Auto Dark Mode) while the terminal keeps a dark color scheme, the CLI repaints its text for a light background but the terminal background stays dark, leaving the UI unreadable.

Still present in 1.0.89-1

#4857 reports this same symptom on Windows and was closed as "resolved as of v1.0.88" by copilot-cli-bot. That closure looks premature - the detection and change-handling code is byte-identical between 1.0.85 and 1.0.89-1 apart from minified identifiers:

if (source === "native") { initial || (u++, m = "native", O()); return }
if (initial)             { l = scheme, d = scheme, x(); return }
scheme !== d && (d = scheme, u++, c = scheme,
                 theme() === "github" ? x() : (m = "terminal", O()))

The hardcoded scheme === "light" ? { bg: #ffffff, fg: #1f2328 } : ... branch and its theme() === "github" || !terminalColors gate are also unchanged in 1.0.89-1.

Root cause

1. Startup probes the terminal with CSI ?996n / CSI ?2031h (2s timeout).
2. Windows Terminal implements neither - DECRQM ?2031 returns 0 on WT 1.24.11911.0. See microsoft/terminal#18375 (open, Backlog; implementation PR #20335 was rejected).
3. The probe times out, so the CLI falls back to the native OS watcher (startColorSchemeListener), which reports the Windows apps theme (AppsUseLightTheme) - not the terminal background.
4. With the default github theme, a light report forces { bg: #ffffff, fg: #1f2328 } regardless of the real background. The text repaint always happens, while the matching background write is gated behind theme === "github" && truecolor && !refreshInFlight, so the two routinely disagree.

Only existing sessions break; a fresh session takes the initial path and renders fine.

Secondary: no recovery path

In 1.0.81-14 the listener re-queries only on an OS theme change, and Xlr() returns just a dispose function, so changing theme never forces a re-query. Once the palette is corrupted, /theme <x> prints "Color mode set to" but the stale bg/fg persist; the only recovery is another OS toggle or a restart. 1.0.85+ adds { modeChanged, dispose }, but a session whose palette is already wrong still cannot self-correct without an external trigger.

Tertiary: race when the terminal also switches

With theme: "system" plus "colorScheme": { "dark": ..., "light": ... }, the forced OSC 11 re-query and the terminal's repaint are both driven by the same WM_SETTINGCHANGE, with no ordering guarantee. The query can read the outgoing scheme, producing the inverse mismatch (light-mode text on the new dark background), with no retry to correct it.

Suggested fixes

1. Prefer OSC 11 over the OS theme. Background lightness is what actually matters, and it stays correct for "light OS theme + dark terminal scheme" users. This is also the Windows Terminal maintainers' guidance in microsoft/terminal#20335; OSC 11 reports the new background promptly on WT 1.24.11911.0.
2. Add a settle delay / retry after an OS theme notification before trusting the query result.
3. Allow pinning light/dark explicitly (already requested in #4620). /theme only selects a palette family (default|github|dim|high-contrast|colorblind); there is no supported way to force dark.

Workaround

/theme dim, or any non-github family - these derive from the queried terminal colors and skip the hardcoded light palette.

Affected version

1.0.89-1 (also 1.0.85, 1.0.81-14)

Steps to reproduce the behavior

1. Windows Terminal with a dark color scheme ("One Half Dark") and "theme": "dark".
2. Set the Windows apps theme to dark, then start copilot.
3. While the session is running, flip the Windows apps theme to light (Auto Dark Mode, or Settings > Personalization > Colors).
4. The terminal background correctly stays dark, but Copilot CLI repaints its text with the light palette - the UI becomes unreadable.
5. On 1.0.81-14, /theme <family> prints "Color mode set to: ..." but does not restore readability.

Expected behavior

Copilot CLI should follow the terminal's actual background (OSC 11) rather than the OS apps theme, and should stay readable when the two disagree. Failing that, provide a supported way to pin light/dark.

Additional context

• Operating system: Windows 11
• CPU architecture: x86_64
• Terminal emulator: Windows Terminal 1.24.11911.0
• Shell: Windows PowerShell
• Auto Dark Mode with AppsSwitch enabled (flips AppsUseLightTheme)
• Reproduced on 1.0.81-14 and 1.0.85; code path verified unchanged in 1.0.89-1