[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 Codex Windows app stuck on blank/spinner at startup — unsupported workspace_dependencies feature loop #19437 / [Bug] Windows Desktop App (26.422.3464.0) white screen on startup due to workspace_dependencies loop #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?

Install OpenAI.Codex 26.831.2377.0 or 26.901.1978.0 from the Store on the machine above.
Launch Codex normally (Start menu, Store, or explorer.exe shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App).
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 [Windows] Blank client area on 26.820.7780.0; --disable-direct-composition restores rendering #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.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

[Windows][26.825.6671.0] App opens to completely white screen while renderer, GPU process and codex.exe are running #41871

Powered by Codex Action

Independent confirmation on a newer Windows 26.901 build. Page.reload is a reliable workaround on my machine, while CalculateNativeWinOcclusion alone is not.

I am seeing essentially the same blank-client-area failure on Windows 11.

Current affected build

About dialog: 26.901.22334, released Sep 3, 2026
Installed MSIX package: OpenAI.Codex_26.901.2854.0_x64__2p2nqsd0c76g0
Package family: OpenAI.Codex_2p2nqsd0c76g0

I previously reproduced the blank-window problem on the 26.831 line as well. Updating to 26.901 did not resolve it.

Symptom

On a normal Store launch the native window opens, including the title bar/window controls, but the client area remains a uniform dark/blank surface indefinitely.

The app does not appear to be crashing.

Earlier diagnostics on the affected installation showed normal startup progress, including the main frame loading, ready-to-show, routes mounting, authentication succeeding, and app-server initialization succeeding.

I also did extensive local-state troubleshooting before reaching the result below:

Windows Repair / Reset
uninstall + reinstall from Microsoft Store
testing with fresh local Codex/ChatGPT state
cleaning/recreating local configuration/state rather than reusing the old profile
GPU-related launch tests
testing both Stable and Beta

A Microsoft Store Beta build on the same Windows installation was able to render normally, while the affected Stable builds remained blank.

Important reproduction on 26.901.2854.0

First I launched the packaged executable directly with:

--disable-features=CalculateNativeWinOcclusion

That produced a visible UI, but it was not a normal full Store activation: only the Work/Codex surfaces were available and my normal Chat/cloud conversations were not present.

I then launched the real Store package through IApplicationActivationManager with:

--disable-features=CalculateNativeWinOcclusion

I verified from Win32_Process.CommandLine that the main ChatGPT.exe process really did receive the flag:

"...\OpenAI.Codex_26.901.2854.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe"
--disable-features=CalculateNativeWinOcclusion

Despite that, the correctly activated Store instance was still completely blank.

So on this newer build, disabling CalculateNativeWinOcclusion by itself is not sufficient on my machine.

What reliably restored the UI

I launched the Store package through IApplicationActivationManager with:

--disable-features=CalculateNativeWinOcclusion --remote-debugging-port=9222

The window was still blank.

The DevTools endpoint was reachable and exposed the main renderer target:

app://-/index.html

I then sent:

{"id":1,"method":"Page.reload","params":{"ignoreCache":true}}

over the renderer's DevTools WebSocket.

Immediately after Page.reload, the complete UI appeared.

I tested the resulting application by navigating through chats, menus and Settings. The normal Chat/Work/Codex UI was present and the application appeared fully functional.

This result is highly repeatable for me:

normal Store launch
    -> blank

Store activation + CalculateNativeWinOcclusion disabled
    -> blank

Store activation + remote debugging
    -> blank

Page.reload on app://-/index.html
    -> full UI renders and remains functional

I now use a small local launcher that performs the same sequence automatically: activate the real Store package, wait for the app://-/index.html renderer, send Page.reload, then exit. This makes the current Stable build usable without modifying WindowsApps or the app package.

Current assessment

This strongly supports the presentation/surface-embedding failure described in this issue rather than corrupted ChatGPT/Codex user data.

On my machine the renderer exists and can be contacted while the visible top-level window remains blank. Reloading the renderer creates/reattaches a surface that Windows then presents normally.

The fact that this still reproduces on package 26.901.2854.0, which is newer than the 26.901 build originally reported here, also indicates that the regression is still present in the current Stable line.

I can provide additional sanitized logs or repeat specific diagnostic tests if useful.

Additional reproduction on 26.831.2377.0 / Windows 11 25H2 / RTX 3070 Laptop

Reporting an additional affected machine, with a successful --disable-direct-composition launch. This adds a different GPU configuration to this issue and overlaps with the workaround in #40878.

Environment

Microsoft Store/MSIX package: OpenAI.Codex 26.831.2377.0, x64; package status OK.
Windows 11 25H2, build 26200.8875.
CPU: Intel Core i7-12700H.
GPU enumerated by Windows: NVIDIA GeForce RTX 3070 Laptop GPU.
Display driver version reported by Windows: 31.0.15.4630.
PowerShell used in the successful manual test: 7.6.5.

The package, OS build, CPU, GPU and driver above were checked locally on 2026-09-05. We have not established the active display routing or a hybrid-GPU cause.

Observed behavior and successful workaround

The user reported that opening the desktop app normally left the window white/blank, while Task Manager showed multiple Codex/ChatGPT processes still running.
After closing the existing app processes and launching the package executable with only --disable-direct-composition, the user confirmed that Codex opened normally.
A subsequent read-only check of Win32_Process verified that the currently running main process actually contains that switch. The GPU-process command line also contains it.

The working launch commands were:

# Fully quit Codex first; finish active tasks before closing it.
$pkg = Get-AppxPackage -Name 'OpenAI.Codex' |
    Sort-Object { [version]$_.Version } -Descending |
    Select-Object -First 1
$exe = Join-Path $pkg.InstallLocation 'app\ChatGPT.exe'
Start-Process -FilePath $exe -ArgumentList '--disable-direct-composition'

Sanitized main-process command line observed locally:

"<WindowsApps>\OpenAI.Codex_26.831.2377.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe" --disable-direct-composition

Evidence limits

This is a user-confirmed successful workaround plus live command-line verification, not a controlled repeated-launch benchmark.
We did not re-run an unflagged launch, reboot test, or force a restart during report preparation, to avoid interrupting active work.
The available record does not establish a valid, command-line-verified outcome for CalculateNativeWinOcclusion alone on this machine.
We did not independently capture renderer screenshots, inspect presentation surfaces, verify all Chat/cloud features, or establish a precise root cause. A rendering/presentation-path problem is a hypothesis supported by the flag response.
Earlier PowerShell ParserError / command-not-found messages came from entering the switch as a standalone command. A credential prompt came from a malformed Start-Process -C:\... invocation. The corrected -FilePath $exe -ArgumentList ... invocation worked; these shell errors are not evidence of a Codex authentication failure.

Could the team investigate this configuration alongside the existing blank-window reports and document a supported persistent workaround for Store installations? Normal launch should display the UI without requiring a Chromium switch.

This report was prepared with Codex assistance at the affected user's request. Only the diagnostic summary and commands are shared; no conversation transcript, raw logs, credentials, personal file paths, or screenshots are uploaded.

Follow-up on 26.901.5280.0: recurring black screen, stalled startup queries and plugin loading; user-confirmed recovery by cancel/refetch

Prepared: 2026-09-06, Asia/Seoul (UTC+09:00).
Follow-up from the original reporter of #42547, prepared with Codex assistance and approved for public posting.
This report intentionally excludes the user's email, account identifiers, conversation IDs, workspace names, tokens, and raw browser/network logs. Contact email can be supplied separately through a private support channel.

Summary and impact

This is additional evidence from the same affected machine on a newer package. It does not retract the original report's renderer-screenshot versus native-window-presentation observations. A frontend query stall and a presentation/surface problem may coexist, and cancel/refetch may also trigger rendering work. We have not performed a controlled experiment separating query completion from repaint/surface effects; recovery after retry is not sufficient to rule out the original compositor/occlusion hypothesis.

The Windows desktop app repeatedly shows its startup logo, then a persistent black window when launched normally from the Start menu. Plugin settings have also remained loading without displaying installed plugins. The app-server and authentication can initialize successfully while frontend initialization queries remain pending/fetching.

Canceling and refetching selected stalled frontend queries, without changing GPU settings or reinstalling plugins, restored the visible app and plugin list. The user confirmed successful recovery and subsequently confirmed successful launch through an automatic recovery shortcut after fully exiting the application. Normal Start-menu launches previously reproduced the black screen after a successful one-time recovery.

This is evidence of a frontend startup/query-lifecycle problem, not proof of the deepest underlying defect. Please investigate and provide an official fix; the current workaround depends on unsupported internal state inspection.

Environment

Windows 11 Pro, 64-bit; OS version 10.0.26200, build 26200.
MSIX package: OpenAI.Codex, version 26.901.5280.0; package status reported Ok.
Start-menu display name: ChatGPT; app ID: OpenAI.Codex_2p2nqsd0c76g0!App.
Manifest executable: app/ChatGPT.exe; entry point: Windows.FullTrustApplication.
App-server reports version 0.153.4. Independently installed npm CLI also reports 0.153.4 and remains usable.
GPU: Radeon RX 570 Series; driver 31.0.12027.9001, dated 2023-03-30.
GPU device status: OK; ConfigManagerErrorCode: 0.
AMD Crash Defender Service and AMD External Events Utility: running, automatic startup.
Locale: ko-KR; timezone: Asia/Seoul.
Earlier local diagnostic reports also covered desktop version 26.901.5003.0. The current confirmed affected package is 26.901.5280.0.
The original issue reported ChatGPT Pro and Chrome 152.0.7977.75. Those values were not rechecked for this follow-up; the current extension version was not recorded.

Reproduction on the affected machine

Fully exit the desktop application, including its tray process.
Launch the registered OpenAI.Codex application from the Start menu, without diagnostic or GPU flags.
Observe the startup logo, followed by a black application window.
Wait approximately 30 seconds or longer. The user repeatedly reported that normal UI did not appear. No controlled maximum-duration measurement was recorded.
Recover the current process by retrying stalled frontend initialization queries as described below.
Fully exit and launch normally again: the black screen recurred in repeated user tests.

Expected: startup resolves into a usable main UI and installed plugin settings, or reports an actionable initialization error and offers a retry.

Actual: the app can remain visually black or show indefinitely loading plugin settings despite successful backend initialization. Exact reproduction rate across all launches is unknown; some diagnostic launches eventually displayed UI.

Observed backend and frontend behavior

Supplied startup logs show these successful milestones:

initialize_handshake_result ... outcome=success transportKind=stdio
Codex CLI initialized
app_server_connection.state_changed ... next=connected
window main frame finished load appearance=primary
window ready-to-show appearance=primary
React root render requested
[chatgpt-account-lookup] completed ... authenticatedAccountPresent=true ... result=succeeded

Numerous account/read, config/read, model/list and thread-related responses were routed with errorCode=null. Earlier diagnostics observed plugin/installed returning installation information while the corresponding settings UI remained loading. These successes do not establish that every frontend query had received and applied its own response.

Direct inspection of React Query state in affected diagnostic launches found selected queries with status=pending and fetchStatus=fetching. Across different runs, affected keys included:

["experimental-features", "list"]
["config", "requirements"]
["config", "user"]
["user-saved-config", "local"]
["config", "read-response"]
["windows-sandbox", "readiness"]

Not all keys were stalled in every run. In the latest verified recovery, the only recorded retried key was ["experimental-features", "list"].

Controlled recovery evidence

Earlier isolated-profile diagnostic: black screen reproduced; canceling/refetching pending initialization queries restored the app. Retrying dependent config/read-response queries subsequently restored plugin settings.
Earlier direct cache invalidation alone did not resolve the user's stuck plugin settings. The exact reason requires engineering investigation; do not assume cache invalidation is equivalent to canceling a pending request.
On 2026-09-06 at approximately 01:17-01:19 KST, the original/default profile was launched with verified diagnostic flags and connected through its actual MSIX-virtualized profile path. Retrying experimental-features/list cleared the inspected pending queries. The user confirmed the app and plugins were visible.
After another normal launch reproduced the issue, a separate local recovery shortcut was created. It discovers the currently registered package, launches the same executable/profile, then retries only allowlisted pending metadata/configuration queries. It does not alter the installed application bundle or GPU settings.
Latest recovery result: started 2026-09-05T16:28:19.109Z, completed 2026-09-05T16:29:08.882Z (2026-09-06 01:28:19-01:29:08 KST). This timing includes deliberate observation intervals and is not a startup latency benchmark.

Sanitized result excerpt:

{
  "state": "queries_released_ui_content_present",
  "snapshot": {
    "ready": true,
    "pending": [],
    "textLength": 1256,
    "controls": 274
  },
  "repairs": [[["experimental-features", "list"]]],
  "visualConfirmationRequired": true
}

DOM text/control counts alone were not treated as proof of visual recovery. The user separately confirmed that the app and plugins were visible, including after fully exiting and relaunching through the recovery shortcut.

The recovery uses the existing query client: cancelQueries with the exact query key, followed by refetchQueries with the exact key and type=active. The revised helper observes a query remaining pending for at least 20 seconds before retrying and allows a further 20 seconds before repeating, to avoid continuously canceling ordinary slow requests. It does not retry chat-generation queries. This is a diagnostic workaround, not a supported API or proposed production fix.

Troubleshooting already performed and confounders

Application removal/reinstallation and Windows restart did not eliminate normal-launch recurrence.
GPU-disable and temporary-profile tests produced mixed results; launch timing and whether flags/profile overrides actually applied were not controlled in all early tests. They are not sufficient to attribute the bug to the GPU.
A later successful recovery used no GPU-disable flags and left GPU driver/service settings unchanged.
A new-profile test reproduced the issue in earlier diagnostics, arguing against an explanation limited to corruption of the existing web profile.
An environment-variable-only user-data-path test was rejected by native startup: "Ignoring late userData path change after native startup". An empty test directory therefore did not constitute a clean-profile test.
The actual default browser profile visible outside the package is under %LOCALAPPDATA%/Packages/OpenAI.Codex_2p2nqsd0c76g0/LocalCache/Roaming/Codex/web/Codex. Native logs can instead name %APPDATA%/Codex/web/Codex. Reading DevToolsActivePort from only the unvirtualized path caused an earlier recovery attempt to fail before connecting.
Earlier diagnostics found that some package activation paths dropped diagnostic arguments. Later tests launched through Invoke-CommandInDesktopPackage and verified the actual process command line, rather than assuming arguments were honored.
Diagnostic CDP binds to 127.0.0.1 on an ephemeral port and ends when the desktop app exits. The shortcut does not change the original Start-menu application registration.
Independent CLI sessions and existing conversation data were preserved during successful recovery. No plugin reinstall was needed for that recovery.

Other warnings: correlation is not causation

Logs also contained a React Router empty leaf-route warning, Windows-unavailable Artifact Session Unix-socket warning, stale rollout-path warnings, ignored experimental feature keys, missing Korean currency translations with fallback, GCM deprecated-endpoint errors, and an unreadable Google Drive extension registration. None was isolated as the cause of the black screen.

Some connection-state logs carried an error object labeled connection-failed while simultaneously reporting state=connected and wrapping backend WARN text. Please review whether such stderr warnings incorrectly affect frontend connection/query lifecycle; this is an investigation lead, not a proven defect.

The Chrome extension earlier displayed: "Unable to start ChatGPT. Codex App-server manifest entry is missing required path nodePath". The user later confirmed the extension also worked, but no direct causal link to query recovery was established and the recovery helper did not edit nodePath or its manifest. Please track this separately if needed.

Requested engineering follow-up

Please correlate these observations with the original presentation-path evidence rather than assuming all blank windows have one established cause. The user remains unable to rely on normal Start-menu startup and needs a supported fix instead of a diagnostic launcher.

Investigate startup initialization and pending-query completion/cancellation across app-server handshake, feature/config loading, and renderer mount.
Review whether a startup response can be lost, applied to an obsolete subscriber, or leave an unresolved promise after a lifecycle transition. These are hypotheses, not established causes.
Add bounded timeout/retry and a visible recoverable error state instead of an indefinitely black/loading UI.
Investigate why plugin UI readiness remains gated when installation information is already available.
Test the Windows MSIX Start-menu launch path and ko-KR environment, including feature/config initialization, with and without diagnostic flags.
Confirm whether this is a known issue and identify an app version containing a fix. The user should not need a local diagnostic launcher for ordinary startup.

Privacy and supporting material

This report is a sanitized synthesis of local diagnostics and explicit user confirmations. Raw session transcripts, cookies, authentication files, GCM stores, network captures, project paths, and conversation contents are intentionally not attached. Any additional requested evidence should be reviewed and shared privately with OpenAI Support.

Same 26.901, worse symptom on Windows 11 (build 26200, x64) — window never becomes visible at all.

OpenAI.Codex 26.901.6511.0 (ChatGPT/Codex desktop, Microsoft Store), Windows 11 Home 26200, x64.

Observed:

Main process launches and stays alive (6 processes incl. helpers), creates Chrome_WidgetWin_0 at the correct size/position, but the window is never shown: WS_VISIBLE is never set (IsWindowVisible = false). No splash, no content, nothing on screen. ShowWindowAsync(SW_SHOW) posts fine but the window never appears, suggesting the UI thread is not pumping / the show is gated by the occlusion logic.
App log at %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\ stops right after Launching app ... platform=win32 and Appshot hotkey inactive configured=true enabled=false; no error, no crash dump. Log also shows [sparkle] in_app_updates_policy_wait_started timeoutMs=300000.
The main process crash-restarts roughly every 2 minutes (main PID keeps changing without any user action).
CLI codex (0.144.5) works fine — only the desktop GUI is affected.

Already tried, none helped:

Full uninstall + clean reinstall from the official installer (ChatGPT Installer.exe, same 26.901.6511.0 build);
Add-AppxPackage -Register (store "Repair");
Killing all ChatGPT.exe processes before launching;
Launching app\ChatGPT.exe --disable-features=CalculateNativeWinOcclusion directly (flag appears not to reach the renderer — window still hidden).

Happy to attach logs or event-log output if useful.

Additional Windows reproduction on 26.903.9818.0: one Page.reload restored the UI

I can add a reproduction from another Windows machine on MSIX package OpenAI.Codex 26.903.9818.0 (x64). The startup black screen recurred on September 11, 2026. This is additional evidence, not a confirmed root cause or a claim that the original presentation/compositor diagnosis is incorrect.

Controlled recovery test

Fully exited the previous Codex instance, then launched the installed package executable with only --remote-debugging-port=<ephemeral port>. The listener was verified as loopback-only and owned by that process. GPU settings and the existing profile were retained.
Waited approximately 25 seconds without a diagnostic connection. Then used a light CDP connection for Page.getFrameTree and a bounded, read-only DOM/React-state probe. This test did not enable the Debugger or Network domains, install logpoints, or cancel/refetch queries.
Confirmed visually that the native app window was still black before reloading.
Sent one Page.reload with ignoreCache: true, guarded by the current frame/loader identity.
The same app process remained running, and I confirmed that the normal UI appeared afterward.

The reload was sent at 2026-09-11 14:47:23 UTC (23:47:23 JST).

Observation	Before reload	Approximately 5 seconds after	Approximately 20 seconds after
DOM element count	194	1,109	1,162

Before reload, the document reported readyState=complete; the root was present, with display:block, visibility:visible, and opacity:1. The sampled current React tree contained loading/pending states. The post-reload React traversal reached its configured limit, so I am not claiming that every query was verified as complete.

Native logs show plugin reconciliation starting approximately 4 seconds after the reload and completing approximately 8 seconds after it. The visual recovery was confirmed separately from those logs and DOM counts.

Controls and limitations

No application-process restart, GPU-disable flag, config-file edit, cache deletion, or manual plugin reinstall was used during this recovery. ignoreCache: true bypassed the cache for that navigation; stored cache was not deleted.
This is one confirmed black-to-visible recovery, not a repeated reliability benchmark. A separate test launch was already visible and correctly skipped reload.
Earlier tests on this machine found that opening the debug port alone, or attaching the full diagnostic recorder after the black screen appeared, did not restore the UI. Early diagnostic attachment sometimes avoided the symptom, but was not consistently sufficient in later runs.
Reload reinitializes both frontend state and presentation surfaces. This result does not distinguish conclusively between an initialization/query-lifecycle problem and a presentation problem.

Could the team investigate this newer affected package and identify a supported fix or recovery action? The current workaround still requires reloading the main renderer after a failed startup.

This comment was prepared with Codex assistance and approved for posting. It contains only a diagnostic summary; no conversation transcript, credentials, account identifiers, personal paths, raw logs, or screenshots are attached.

Navigation Menu

Repository navigation

[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 #42547

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Additional reproduction on 26.831.2377.0 / Windows 11 25H2 / RTX 3070 Laptop

Follow-up on 26.901.5280.0: recurring black screen, stalled startup queries and plugin loading; user-confirmed recovery by cancel/refetch

Summary and impact

Environment

Reproduction on the affected machine

Observed backend and frontend behavior

Controlled recovery evidence

Troubleshooting already performed and confounders

Other warnings: correlation is not causation

Requested engineering follow-up

Privacy and supporting material

Additional Windows reproduction on 26.903.9818.0: one Page.reload restored the UI

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[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 #42547

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Sep 3, 2026

vizelio48 commented on Sep 3, 2026

NORMALSALINE0413 commented on Sep 4, 2026

Additional reproduction on 26.831.2377.0 / Windows 11 25H2 / RTX 3070 Laptop

LeeDKuen commented on Sep 5, 2026

Follow-up on 26.901.5280.0: recurring black screen, stalled startup queries and plugin loading; user-confirmed recovery by cancel/refetch

Summary and impact

Environment

Reproduction on the affected machine

Observed backend and frontend behavior

Controlled recovery evidence

Troubleshooting already performed and confounders

Other warnings: correlation is not causation

Requested engineering follow-up

Privacy and supporting material

mtitanic777 commented on Sep 6, 2026

yousuke106 commented on Sep 11, 2026

Additional Windows reproduction on 26.903.9818.0: one Page.reload restored the UI

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions