[Windows] Blank client area on 26.831 / 26.901 (Chromium 152): renderer paints but window never shows it; --disable-features=CalculateNativeWinOcclusion avoids it, Page.reload restores it

Related: #40878 (same blank-client-area phenotype on 26.820/26.825). This report adds a newer version line (26.831 / 26.901, Chromium 152), a launch flag that has been deterministic on this machine so far, evidence that the renderer keeps painting while the window never shows it, and a way to pass Chromium switches to the Store (MSIX) package.

What version of the Codex App are you using (From "About Codex" dialog)?

• OpenAI.Codex 26.831.2377.0 (Store/MSIX, internal app version 26.831.21537) - first launch on 2026-09-03 was blank
• OpenAI.Codex 26.901.1978.0 (internal 26.901.20858) - same behavior
• Both embed Chromium 152.0.7977.64 (ChatGPT.exe file version; /json/version reports Chrome/152.0.7977.64). The 26.831 bundle declares electron: 42.3.0.
• The previous package 26.825.6671.0 (Chromium 151.0.7922.174) rendered normally on the same machine on 2026-09-02, one day earlier.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Pro 25H2, build 26200.9168)

• CPU AMD Ryzen 5 2600, 24 GB RAM
• GPU AMD Radeon RX 570, driver 31.0.12027.9001 (2023-03-30), ANGLE D3D11, feature level 12_0
• Two displays, both at 100% scaling: 1920x1080 (primary) and 2560x1440
• Google Chrome 152.0.7977.75 and an Electron 42 / Chromium 148 app render normally on the same GPU and driver at the same time.

What issue are you seeing?

After the Store update to 26.831 the main window opens but the whole client area is a single flat color, #202020, which is the BrowserWindow backgroundColor for the dark theme (the opaque, non-Mica surface path). The window caption buttons (minimize / maximize / close) are drawn; nothing else is. Updating to 26.901 did not change it. Every normal launch since the update has been blank.

What I verified while the window was blank:

• The app is alive and working. The main process logs a normal startup with no errors: window main frame finished load, window ready-to-show, app routes mounted after ~9 s, app-server handshake OK. Renderer, GPU and utility processes stay alive; Local State reports exited_cleanly: true and system_crash_count: 0.
• The renderer is painting the full UI. Attaching DevTools over --remote-debugging-port and calling Page.captureScreenshot on app://-/index.html returns the complete Codex UI (sidebar, projects, home composer). document.body.innerHTML is ~600 KB, #root has a React root, document.visibilityState is visible, document.hidden is false, devicePixelRatio is 1, inner size matches the window (1280x820).
• The presented window content is flat. PrintWindow(PW_RENDERFULLCONTENT) of the top-level window samples exactly one color (#202020) over the whole client area; a UI Automation walk of the window shows only the caption buttons (accessibility for the web content was not enabled, so this is only a secondary signal).
• GPU status is normal. SystemInfo.getInfo over CDP: gpu_compositing: enabled, rasterization: enabled, webgl/webgpu: enabled, skia_graphite: disabled_off, direct_rendering_display_compositor: disabled_off_ok, directComposition: true, supportsOverlays: false, skiaBackendType: GaneshGL, processCrashCount: 0. Driver bug workarounds: disable_direct_composition_sw_video_overlays, disable_nv12_dynamic_textures, disable_video_overlay_if_moving, exit_on_context_lost, force_rgb10a2_overlay_support, limit_d3d11_video_decoder_to_11_0, ... (the usual AMD set).
• Window structure is identical to a painting instance: top-level Chrome_WidgetWin_1 with WS_EX_NOREDIRECTIONBITMAP, children Chrome_RenderWidgetHostHWND (visible) and Intermediate D3D Window (visible, not cloaked, same size as the client area).
• One Crashpad sidecar was written at the very first launch of 26.831: {"capture_kind":"dump_without_crashing","ptype":"gpu-process"}. Later blank launches wrote no reports.
• Auth is fine (getAuthStatus / account/read succeed, ChatGPT API calls return 200) and this is not the workspace_dependencies loop from #19437 / #19770.

So the frames exist in the renderer / viz surface but are never composited into what the window presents. A page reload gives the window a new surface and it appears immediately.

What steps can reproduce the bug?

1. Install OpenAI.Codex 26.831.2377.0 or 26.901.1978.0 from the Store on the machine above.
2. Launch Codex normally (Start menu, Store, or explorer.exe shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App).
3. Wait 45 s or longer. The client area stays flat #202020.

Counts on this machine (each measured at least 45 s after launch by sampling the window pixels; "painted" means the normal UI is visible):

Launch	Result
Normal launch, no switches (26.831 x2 by the user, 26.901 x3 in controlled runs)	5 / 5 blank
Same package launched with --disable-features=CalculateNativeWinOcclusion (26.901 x3, two of them also with --remote-debugging-port=9222)	3 / 3 painted, document.visibilityState = visible
Blank instance, then Page.reload sent over CDP	2 / 2 painted within 20 s, no restart needed

Things that did NOT recover a blank instance (each verified by re-sampling the window): minimize + restore, hide + show (SW_HIDE/SW_SHOW), maximize + restore, resizing by 40 px, moving the window inside the monitor and to the other monitor, attaching DevTools (Runtime.enable / Log.enable), Page.captureScreenshot, Emulation.setDeviceMetricsOverride + clearDeviceMetricsOverride, hiding and re-showing the Chrome_RenderWidgetHostHWND child, fully covering the window with another app and uncovering it, and installing the pending 26.901 update.

To pass Chromium switches to the Store package without losing package identity, activate it through IApplicationActivationManager (the flags are otherwise unreachable on Store builds, as noted in #23624):

$src = @"
using System; using System.Runtime.InteropServices;
public enum ActivateOptions { None = 0 }
[ComImport, Guid("2e941141-7f97-4756-ba1d-9decde894a3d"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IApplicationActivationManager {
  [PreserveSig] int ActivateApplication([In, MarshalAs(UnmanagedType.LPWStr)] string aumid, [In, MarshalAs(UnmanagedType.LPWStr)] string args, [In] ActivateOptions o, [Out] out uint pid);
  [PreserveSig] int ActivateForFile([In, MarshalAs(UnmanagedType.LPWStr)] string aumid, [In] IntPtr items, [In, MarshalAs(UnmanagedType.LPWStr)] string verb, [Out] out uint pid);
  [PreserveSig] int ActivateForProtocol([In, MarshalAs(UnmanagedType.LPWStr)] string aumid, [In] IntPtr items, [Out] out uint pid);
}
[ComImport, Guid("45BA127D-10A8-46EA-8AB7-56EA9078943C")] public class ApplicationActivationManager {}
public static class L { public static uint Go(string aumid, string args) { uint pid; var m = (IApplicationActivationManager)new ApplicationActivationManager(); m.ActivateApplication(aumid, args, ActivateOptions.None, out pid); return pid; } }
"@
Add-Type -TypeDefinition $src
[L]::Go('OpenAI.Codex_2p2nqsd0c76g0!App', '--disable-features=CalculateNativeWinOcclusion')

The switch shows up on the main process command line and the app runs as the normal Store package.

What is the expected behavior?

The window should present the UI that the renderer is already painting, on every launch, without Chromium switches or a reload.

Additional information

• Working hypothesis, not proven: with native window occlusion tracking enabled, the window's visibility flips during startup (created hidden, shown, briefly judged occluded, then visible again) and that transition races with the first surface embedding, so the browser side keeps drawing the background color and never embeds the renderer's surface; a reload creates a new surface and fixes it. --disable-features=CalculateNativeWinOcclusion removes the occlusion flip, which matches the 3 / 3 result. The 5 / 3 / 2 counts are small; happy to run more launches or a diagnostic build.
• The client area is #202020 here, i.e. the opaque surface path, not the transparent / Mica path discussed in #40878, so that path is affected too.
• The machine's AMD driver is old, but Chrome 152 and other Chromium-based apps present normally on it, and the GPU process reports no crashes or lost contexts during the blank launches.
• The "Reload Window" application-menu item is registered with the accelerator Command+Control+R, which does not exist on Windows, so an end user has no keyboard way to trigger the reload that fixes the window. A working Windows accelerator (for example Ctrl+Shift+R) would be a cheap mitigation while the root cause is being fixed.
• Logs (main-process desktop logs, Crashpad sidecar, CDP dumps) are available on request; I can also upload through /feedback if that is preferred.

Start by tracing the Windows desktop startup path around BrowserWindow creation, the ready-to-show event, and the first renderer surface presentation. Reproduce the blank launch with and without --disable-features=CalculateNativeWinOcclusion, then compare it with Page.reload; done means the Store build consistently presents the rendered UI without a switch or reload.