[Windows] First launch shows no window for about 15 minutes while extracting bundled cua_node runtime
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-<id>
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?
- Install or update the Windows Codex desktop app.
- Launch it for the first time from the Start menu.
- Observe that ChatGPT.exe processes start, but no application window appears.
- Check the Codex desktop log and the runtime directory under:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node
- Observe that the bundled cua_node runtime is extracted slowly into a staging directory.
- Wait approximately 15 minutes.
- 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.
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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_noderuntime 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
WindowsAppsor 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.
Same problem, after update ChatGPT app , Windows 11 25H2 26200.9168 ;
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
I can reproduce this on Windows with Codex app version
26.820.9563.0.Observed behavior:
After the window finally appeared, PowerShell showed multiple
ChatGPT.exeprocesses from the AppX package plus the Codex CLI process. The earliestChatGPT.exeinstances hadStartTimearound09:27:01, with additional renderer/helper processes appearing around09:27:21and09:29:36–09:29:50;codex.exestarted around09:29:37.Package version:
Relevant process paths after startup completed:
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.
I have the same problem.