[Windows] Blank client area on 26.820.7780.0; --disable-direct-composition restores rendering

2. What version of the Codex App are you using?

26.820.7780.0

(Store package version - worth a glance at Help > About Codex to confirm it matches.)

3. What subscription do you have?

ChatGPT Plus

4. What platform is your computer?

Run this in PowerShell, paste the single line it prints:

"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })"

5. What issue are you seeing?

After the Microsoft Store update from 26.818.8289.0 to 26.820.7780.0, the app opens with a completely blank client area. The window, caption buttons and process are all alive - the renderer mounts, routes mount, auth succeeds, IPC round-trips complete, and remote control from the phone works normally - but the web contents never paint.

Launching the same signed package executable with only --disable-direct-composition renders the full UI correctly. That single flag is the entire difference.

This is not a machine-wide DirectComposition failure. Chrome 151.0.7922.175 and Edge 151.0.4129.107 both render normally on the same machine with DirectComposition enabled. Chrome is five patch revisions from the Chromium 151.0.7922.170 this build embeds.

Measurements. The client area below the caption strip was screen-captured and sampled by luminance. A blank window scores 1 luminance level and 0.000% deviation from the modal value - one flat color across ~190,000 sampled pixels.

Configuration	Result
Unflagged, direct exe launch	Blank: 1 level, 0.000%
Unflagged, Store identity launch	Blank: 1 level, 0.000%
Unflagged, moved across all 3 monitors	Blank on each
--disable-features=CalculateNativeWinOcclusion	Blank: 1 level, 0.000%
--disable-direct-composition	Painted: 99 levels, 6.558%
Parsec virtual display adapter disabled, unflagged	Blank on both launch paths
Chrome 151.0.7922.175, own top-level window	Painted
Edge 151.0.4129.107, own top-level window	Painted

Also ruled out: --disable-gpu, cache clearing, a full Reset-AppxPackage with a fresh profile, and package repair.

This produces no error signal. Every startup log line reports success - window ready-to-show, React root render requested, routes mounted, auth resolved, no renderer or GPU process-gone marker, no exception. Crash telemetry will show these sessions as healthy. This failure mode is only visible if a human reports it.

Hardware and display configuration:

• Executable ChatGPT.exe, embedded Chromium 151.0.7922.170, package OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• NVIDIA RTX 5060 Ti, driver 32.0.16.1088 (2026-07-21)
• Three 4K DisplayPort monitors: 160 Hz primary, plus two at 60 Hz with Advanced Color enabled on one
• Mixed DPI: 175% user / 150% system
• Onset: Store update installed 2026-08-25 20:22; Windows logged a MoAppHang for ChatGPT.exe at 20:29

6. What steps can reproduce the bug?

1. Windows 11 build 26200, NVIDIA GPU, multiple 4K monitors with mixed refresh rates and HDR enabled on one panel.
2. Update the Codex app from 26.818.8289.0 to 26.820.7780.0 through the Microsoft Store.
3. Launch the app normally from the Start menu tile.
4. The window opens and Windows draws its caption buttons, but the client area is a single flat color and never paints. The app is otherwise healthy: logs show the primary window ready-to-show, React root render requested, routes mounted and auth resolved, and remote control from the phone works.
5. Quit the app, then launch the same executable directly with the flag:

$pkg = Get-AppxPackage -Name 'OpenAI.Codex' | Sort-Object Version -Descending | Select-Object -First 1
Start-Process (Join-Path $pkg.InstallLocation 'app\ChatGPT.exe') -ArgumentList '--disable-direct-composition'

6. The UI renders correctly. Removing the flag reproduces the blank window every time.

7. What is the expected behavior?

The client area should paint the app UI, as it did on 26.818.8289.0 and as Chrome and Edge on the same Chromium 151 branch still do on this machine.

Secondarily: when a presentation path fails, the app should fall back to one that works rather than leaving a uniform blank surface. A window that renders nothing while reporting a fully successful startup is very expensive to diagnose, and invisible to your own telemetry.

8. Additional information

Two traps that cause false "already tested" claims. Both cost hours here and may be affecting other blank-window reports:

• --disable-gpu does not bypass DirectComposition. On Windows, Chromium still presents through DComp with the GPU disabled, so that flag never exercises the broken path. "Tried --disable-gpu, still blank" does not rule out DComp.
• Relaunching via explorer.exe shell:AppsFolder\<PFN>!App silently drops command-line arguments. Any flag test performed that way tested nothing.

Requests:

1. Investigate the DirectComposition / swap-chain configuration change between 26.818.8289.0 and 26.820.7780.0.
2. Fall back from a failed presentation path instead of leaving a uniform blank client area.
3. Document a supported way to pass Chromium switches to the signed Store build. Launching the exe directly works and retains package identity and the AUMID, but it is not a documented path, and cold codex:// protocol activation has no way to carry the switch.

Possibly related: #34351 (different rendering symptom, but also Windows build 26200), #33192 and #38710 (other Windows DWM/composition reports).

Update: the flag is not a complete workaround. A launch ~2 minutes after a reboot
produced the blank window despite carrying --disable-direct-composition; a relaunch
~8 minutes after the same boot painted normally. Same build, same flag, same
machine. Either the presentation setup fails while the display stack is still
initializing after boot, or the flag reduces rather than eliminates the failure.

No source files or tests are named. Start by reproducing the blank client area on Windows 11 with the listed multi-monitor configuration, comparing normal launch with --disable-direct-composition and the two app versions. Done means the client area reliably paints after the update and a failed presentation path does not leave a silent uniform blank window.