[Windows app] Intermittent blank startup on 26.901.6511.0: main UI DOM absent, Page.reload recovers, GPU/occlusion flags ineffective

Summary and impact

Codex for Windows intermittently opens to an entirely blank light-colored client area. Only native window controls remain visible; the sidebar and composer are absent. This repeatedly interrupts daily work and has persisted after reinstalling and updating the app. Please prioritize investigation of startup UI initialization and provide a supported workaround or fixed build. I can help validate a fix and collect additional targeted diagnostics.

This report was prepared with Codex assistance from local observations and captures, and submitted with the affected user's authorization. The exact root cause is not established.

Version and environment

• Store/MSIX package: OpenAI.Codex 26.901.6511.0, package status OK.
• ChatGPT.exe file/product version: 152.0.7977.83 (not the Codex package version).
• Windows 10 Pro 19045.7663, x64.
• Lenovo ThinkPad X13 Gen 5, model 21LUA096CD.
• Intel Core Ultra 5 125H; approximately 32 GB RAM (31.5 GiB reported usable/installed by WMI).
• Intel Arc Graphics, driver 32.0.101.8826.
• Display 1920 x 1200; observed renderer devicePixelRatio 1.25.
• Chinese-language UI. Evidence collected on September 6, 2026; times below are UTC+03:00.
• Earlier diagnostic sampling showed roughly 20 GB available RAM and low CPU/disk load; this was not a full stress test and does not rule out every environment interaction.

Reproduction

1. Fully exit Codex and launch it again on this machine.
2. Some launches render normally within approximately 8 seconds. Other launches stay completely blank for at least two minutes.
3. The main process and app-server remain running. Mobile remote access can still send messages and local commands can execute while the desktop window is blank.

No deterministic launch sequence or reliable overall failure rate is established. The issue occurred before adding diagnostic flags and also during instrumented launches.

Captured normal versus blank startup

A collector was started before application activation, then connected to the loopback Chromium debugging endpoint as soon as available. Runtime/Network/Page listeners were enabled about 2.8-2.9 seconds after collector startup. This can still miss events before the endpoint becomes accessible. No request/response bodies, cookies or authentication headers were collected.

On the blank main target (app://-/index.html), document.readyState is complete, visibility is visible, and Page.captureScreenshot itself is blank, consistent with the actual desktop. The normal sidebar/composer DOM is missing. This is not simply a case where a complete UI screenshot exists inside the renderer but is not presented by the native window.

The app's main-process log nevertheless reports app routes mounted. Other observed messages include fs/readFile / os error 3 and sometimes Conversation state not found; these have not been proven causal. ResizeObserver loop messages also occur during normal operation and are not a reliable white-screen indicator.

net::ERR_ABORTED requests mostly map to sentry-ipc: and also occur in normal launches. They should not be treated as proof of an internet connectivity failure.

Recovery and unsuccessful workarounds

• A single Page.reload on the exact main page restores the UI without restarting the application process or deleting any data. This has been observed repeatedly, including actual desktop screenshot verification on an earlier run.
• In the latest recovery at 21:29:03, two pre-refresh samples five seconds apart both had 0 visible characters / 192 elements. After the refresh, the page had 103 visible characters / 597 elements and the internal screenshot showed the normal homepage.
• --disable-gpu: confirmed present on the main-process command line during a failed test; still blank.
• --disable-features=CalculateNativeWinOcclusion: independently confirmed present during a failed test; still blank.
• Reinstalling and updating did not eliminate recurrence. Old application databases/caches were not restored from the user's migration backup.

Related but potentially different: #42547. Unlike that report, our captured main-page screenshot is itself blank, the main UI DOM is absent, and the occlusion workaround did not solve it. Please link/merge if engineering determines the underlying cause is shared.

Evidence availability and limitations

Local artifacts include timestamped startup timelines, before/after internal and desktop screenshots, recovery metrics, and per-process application logs. They contain private account/workspace material and are intentionally not attached publicly. Please specify a secure support channel and the minimal additional data needed; a sanitized extract can be prepared.

An earlier collector could reconnect across manual application restarts; it was corrected to pin the browser instance. The latest 21:26:46 blank capture is separated from the preceding normal launch. Debugger attachment itself may affect timing, so a startup ordering/race hypothesis remains a hypothesis rather than a confirmed diagnosis.

Please advise whether this matches a known frontend initialization defect, which additional startup/IPC traces are needed, and whether there is a supported temporary recovery action that does not require enabling a debugging port.

No source files or tests are named. Start by reproducing normal and blank launches on the stated Windows environment, then compare the main page through the loopback Chromium debugging endpoint and review the startup timelines and application logs. Done means identifying the initialization failure and providing a validated supported recovery action or fixed build.