[Windows] First launch shows no window for about 15 minutes while extracting bundled cua_node runtime

[Gong-Yie]

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

26.820.9563.0

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows, the Codex desktop app appears not to launch on the first run.

The app process starts and remains running, but no window is shown for approximately 15 minutes. Windows Event Viewer records Application Hang / MoAppHang events for ChatGPT.exe.

The package is installed and registered successfully:

• Package: OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0
• Package status: Ok
• Entry point: app/ChatGPT.exe
• ChatGPT.exe exists and has a valid OpenAI signature
• The OS version satisfies the package minimum version

The application log initially contains only:

Launching app ...
Appshot hotkey inactive ...

During this period, the app creates:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node.staging-

The bundled cua_node runtime contains approximately 334 MB and 4,680 files. The staging directory is populated very slowly while the main ChatGPT.exe process consumes CPU. No startup progress or status is shown to the user.

After the runtime extraction completed, the log reported:

• app-server connection established
• Codex CLI initialized
• [startup][renderer] app routes mounted
• rendererWindowVisible=true

The application window then appeared and the app became usable.

I also tested launching ChatGPT.exe with --no-sandbox. This did not make the window appear sooner.

What steps can reproduce the bug?

1. Install or update the Windows Codex desktop app.
2. Launch it for the first time from the Start menu.
3. Observe that ChatGPT.exe processes start, but no application window appears.
4. Check the Codex desktop log and the runtime directory under:
   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node
5. Observe that the bundled cua_node runtime is extracted slowly into a staging directory.
6. Wait approximately 15 minutes.
7. After extraction finishes, the application window appears.

The issue is most visible on the first launch after installation or update.

What is the expected behavior?

The application should display its window promptly, or show a clear first-run initialization/progress state while the bundled cua_node runtime is being prepared.

A first launch should not appear hung or generate Application Hang / MoAppHang events while the runtime is being extracted.

Additional information

The package and application files are installed through Microsoft Store/AppX. The WindowsApps directory and the package user-data directory are redirected through junctions to the D: drive.

The issue was eventually resolved in the same session after the runtime extraction completed. I have not yet measured a clean second launch after the runtime was fully installed.

No account credentials, API keys, tokens, or personal prompts are included in this report.

[github-actions]

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

• Windows ChatGPT/Codex Desktop 26.820.9563.0 can hang ~8 minutes before creating its main window #41056
• [Windows] 26.820.9563.0 startup hang with high CPU; multi-module preload restores launch #41064

Powered by Codex Action

[zemeng5208]

I maintain WinBridge Recovery, a Windows Codex Desktop local-state diagnostic/recovery project: https://github.com/zemeng5208/winbridge-recovery

This report is a good match for one of the local layers WinBridge specifically checks: bundled cua_node runtime relocation/materialization into %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node, including incomplete .staging-* directories, version/hash consistency, and path/Junction conditions around the source and destination.

In this case I would first distinguish a slow but eventually complete materialization from a damaged/partial runtime. WinBridge can inspect whether the staging tree actually completes, whether the active runtime matches the currently installed official MSIX payload, and whether stale staging/version state or cross-volume/reparse-point paths are contributing. It can recover user-side runtime state when that state is incomplete or inconsistent; it does not modify WindowsApps or take ownership of protected package files.

There is an important limitation here: the issue says the same first launch eventually completed and the UI appeared after the ~334 MB / ~4,680-file extraction finished. If the runtime hashes/state are healthy and Codex is simply performing a synchronous, very slow extraction before first-window creation—especially with the package/user-data paths redirected across volumes—that startup blocking/progress behavior is an upstream Desktop/runtime-materialization performance problem. WinBridge may help verify that boundary, but it cannot guarantee a speed-up or a permanent fix for the app's extraction strategy.

[Activer007]

Same problem, after update ChatGPT app , Windows 11 25H2 26200.9168 ;

[alvinccli]

I can report that I encountered the same issue. Initially I thought something else is wrong, so I repaired the app (using windows add/remove programs), doesn't work. Uninstalled and reinstalled, doesn't work.
Ended up waiting extra long works.

Windows 11 25H2 26200.9168
ChatGPT Version 26.820.80927

[jennyy599-hub]

I can reproduce this on Windows with Codex app version 26.820.9563.0.

Observed behavior:

• Launching the app from its normal icon shows the Windows blue loading cursor briefly, then the cursor returns to normal and no window appears.
• At first it looks as though the app did not launch at all; no obvious Codex window is present and I did not initially notice a relevant process in Task Manager.
• Roughly 5–6 minutes later, the Codex window suddenly appeared without any further action.

After the window finally appeared, PowerShell showed multiple ChatGPT.exe processes from the AppX package plus the Codex CLI process. The earliest ChatGPT.exe instances had StartTime around 09:27:01, with additional renderer/helper processes appearing around 09:27:21 and 09:29:36–09:29:50; codex.exe started around 09:29:37.

Package version:

OpenAI.Codex 26.820.9563.0
OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0

Relevant process paths after startup completed:

C:\Program Files\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe
C:\Users\<user>\.codex\.sandbox-bin\codex.exe

So from the user's perspective this looks like a silent launch failure, but the app eventually becomes usable after several minutes. A visible first-run/update initialization indicator would make this much less confusing, even before the underlying startup delay is fixed.

[guiwushengzhe-prog]

I have the same problem.