Windows ChatGPT/Codex Desktop 26.820.9563.0 can hang ~8 minutes before creating its main window

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

• #40972

Powered by Codex Action

Update after additional observation/log capture:

The app eventually created its main window after a long delay rather than remaining permanently windowless.

• Main ChatGPT.exe process start time: approximately 13:41:56 local (05:41:56Z)
• A real main window was finally present by ~13:49:36 local (05:49:36Z), i.e. roughly 7m40s later.
• At that point the process had a non-zero MainWindowHandle and the log reported rendererWindowVisible=true.

The later startup log contains repeated bundled plugin marketplace copy failures such as:

[BundledPluginsMarketplace] plugin_marketplace_folder_write_failed
UNKNOWN: unknown error, copyfile
'C:\Program Files\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\sites\.app.json'
-> 'C:\Users\CC\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-...\plugins\sites\.app.json'

These errors repeat during bundled_plugins_reconcile, although reconciliation continues afterward, so I cannot say they are the direct cause of the initial hang.

The same session also performed a missing primary-runtime install:

primary_runtime_bundle_install_outcome ... bundleVersion=26.826.11250 durationMs=108709 ... outcome=installed ... trigger=startup_missing
install-primary-runtime ... durationMs=110967 ... status=installed

However, this install completed after the window was already visible, so it does not by itself explain the full ~7m40s pre-window delay.

There is also a later recoverable plugin status error corresponding to The system cannot find the path specified (os error 3), after which the spreadsheets plugin is installed successfully.

The bot suggested #40972 as a possible duplicate. That issue is notably similar because it reports a ChatGPT.exe process with MainWindowHandle=0 that is suspended and later becomes healthy after resume. I did not capture thread state / WaitReason while this machine was in the stuck state, so I cannot yet confirm whether the same suspended-process mechanism is occurring here. If the hang reproduces, I can capture thread count, working set, and thread WaitReason before the window appears.

Withdrawn.

Additional reproduction on 26.825.4187.0 — repeated .staging-* runtime extraction

I reproduced the long/no-window startup behavior on another Windows 11 x64 machine after the Microsoft Store package updated through 26.825.3734.0 to:

OpenAI.Codex 26.825.4187.0
Package status: Ok

The installed MSIX app starts multiple ChatGPT.exe background processes, but the visible window can remain absent for a long time.

New runtime-cache observation

The relevant runtime root is:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

A completed runtime from an earlier build exists:

759ccb73c5d75f83

For the current build, the expected completed directory never appeared:

e4d75eceaa042f20

Instead, each separate failed/aborted launch attempt created a new randomly suffixed staging directory, for example:

.staging-e4d75eceaa042f20-GNd2bb
.staging-e4d75eceaa042f20-aG7HPS
.staging-e4d75eceaa042f20-kkkCpz
.staging-e4d75eceaa042f20-iulHyr
.staging-e4d75eceaa042f20-rizfHG
.staging-e4d75eceaa042f20-Ynlda5

Later launches did not continue writing to the earlier staging directories. They started a fresh staging directory instead. The six incomplete directories accumulated approximately 1,276.9 MB before being removed after recording the evidence.

After cleanup, the state was:

ExpectedRuntimeExists: False
PreviousRuntimeExists: True
RemainingMatchingStaging: 0

Control test

As a diagnostic control, the complete packaged app directory was copied to a normal user-writable folder under %LOCALAPPDATA% and launched directly. That unpackaged copy opens quickly and reliably:

• renderer appears about 2.5 seconds after the main process starts
• app-server appears about 3.1 seconds after the main process starts

This manual copy is only a diagnostic control, not a recommended workaround. It suggests the machine, GPU, and Electron renderer can initialize normally, while the Store/MSIX launch path repeatedly enters or restarts runtime preparation.

Questions for maintainers

Could the Windows runtime installer:

1. log why e4d75eceaa042f20 is never promoted from staging,
2. reuse or clean failed staging directories instead of creating a new full copy on each launch, and
3. avoid blocking main-window creation while runtime preparation is incomplete?

No full logs are attached here because they may contain local paths or session data, but sanitized excerpts can be provided if useful.