›_ Codex Issues
Codex Issues / #28245

Codex Desktop 26.609.3341.0 crashes on Windows due to incomplete cua_node runtime setup

Open 💬 6 comments Opened Jun 15, 2026 by saklbio
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Codex Desktop 26.609.3341.0

What subscription do you have?

ChatGPT Plus subscription

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Windows GUI crashes immediately after launch.

After launching the app, the window appears briefly and closes within a few seconds. The CLI works, but the desktop GUI does not stay open.

Each launch creates an empty .staging-* directory under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

For example:

.staging-789504f803e82e2b-xxxxxx

However, the expected runtime files are never created:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\manifest.json
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\bin
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\789504f803e82e2b

The desktop log only contains the initial two startup lines, and Crashpad dump files are generated on every launch.

I was able to work around the issue by copying a working cua_node folder from another PC where Codex Desktop runs correctly.

What steps can reproduce the bug?

  1. Install or update Codex Desktop on Windows to version 26.609.3341.0.
  2. Launch Codex Desktop from the Start menu or with:
explorer.exe "shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App"
  1. The Codex Desktop window appears briefly.
  2. Within a few seconds, the GUI closes unexpectedly.
  3. Check the runtime directory:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node
  1. A new empty staging folder is created on each launch, for example:
.staging-789504f803e82e2b-xxxxxx
  1. The expected runtime files/folders are not created:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\manifest.json
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\bin
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\789504f803e82e2b
  1. Check the desktop logs under:
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs

The log only contains the initial startup lines.

  1. Check the Crashpad reports directory. A new .dmp file is generated on each launch.

What is the expected behavior?

Codex Desktop should launch successfully and remain open.

If the cua_node runtime is missing or incomplete, the app should automatically create, unpack, or re-download the required runtime files, including manifest.json, bin, and the expected hashed runtime directory.

The app should not repeatedly create empty .staging-* folders and then crash. If runtime setup fails, the desktop log should include a clear error message explaining what failed and how to recover.

Additional information

Additional observations:

  • The Windows user profile path contains non-ASCII characters.
  • CODEX_HOME and HOME were set to an ASCII-only path, but this did not fix the GUI crash.
  • The CLI/runtime files under %LOCALAPPDATA%\OpenAI\Codex\bin\<hash> existed.
  • However, the cua_node runtime under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node was never created correctly.
  • Each GUI launch only created an empty .staging-789504f803e82e2b-* directory.
  • Reinstalling Codex Desktop and resetting local data did not fix the issue.
  • WebView2 was installed and Windows Defender did not report any detection or block.

Workaround that fixed the issue:

I copied the entire cua_node folder from another Windows PC where Codex Desktop was working correctly.

Source on working PC:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

Destination on affected PC:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

After copying the working cua_node folder, Codex Desktop launched successfully and stayed open.

This suggests that the crash is related to incomplete cua_node runtime setup or recovery, not the CLI itself.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27506
  • #27409
  • #27546

Powered by Codex Action

saklbio · 2 months ago

Thanks for the duplicate detection.

This issue is likely related to the linked non-ASCII Windows user profile / cua_node staging issues, but I believe this report adds one additional confirmed detail:

In my case, every .staging-789504f803e82e2b-* directory created under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

was completely empty.

There was no manifest.json, no bin directory, and no completed 789504f803e82e2b runtime directory anywhere under cua_node.

The GUI crashed before the cua_node runtime was unpacked or finalized.

The workaround that fixed the issue was copying the entire working cua_node folder from another Windows PC where Codex Desktop was running correctly into the affected PC at the same path:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

After that, Codex Desktop launched successfully.

So this does appear related to the existing non-ASCII/staging issues, but this issue documents a confirmed workaround for the case where the staging directories are empty and the runtime files are never created.

Z1WZ05 · 2 months ago

how to solve it?

saklbio · 2 months ago
how to solve it?

For me it was fixed by copying the complete cua_node runtime folder from another Windows PC where Codex Desktop was working.

Source on working PC:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node
Before copying, every .staging-* directory under cua_node was empty and there was no manifest.json, no bin, and no completed runtime directory.

After copying the full cua_node folder, Codex Desktop launched successfully.

This is only a workaround, not an official fix.

Z1WZ05 · 2 months ago
> how to solve it? For me it was fixed by copying the complete cua_node runtime folder from another Windows PC where Codex Desktop was working. Source on working PC: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node Before copying, every .staging-* directory under cua_node was empty and there was no manifest.json, no bin, and no completed runtime directory. After copying the full cua_node folder, Codex Desktop launched successfully. This is only a workaround, not an official fix.

Thank you very much for your reply.
Our problem lies in the same location, specifically in the .staging-789504f803exxxxx-xxxxxx file under: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node.
The issue I encountered is that such folders keep being created repeatedly, with each folder containing manifest.json and the bin folder as shown in the image, resulting in a significant amount of disk space being occupied on the C drive.

<img width="311" height="398" alt="Image" src="https://github.com/user-attachments/assets/895f9ead-98e9-4203-bfd1-2642abe80f3e" />

<img width="350" height="452" alt="Image" src="https://github.com/user-attachments/assets/4e516277-6104-4e0e-ab0d-99e6ba4b892a" />

My previous temporary solution was to delete all similar folders. From the current usage, it seems that it didn't cause any more problems.

zemeng5208 · 13 days ago

Disclosure: I maintain WinBridge Recovery, an independent Windows Codex Desktop recovery tool: https://github.com/zemeng5208/winbridge-recovery

This thread is especially relevant because the confirmed workaround — copying a complete cua_node runtime from another working PC — strongly suggests the local runtime staging/finalization layer is the broken part, not the model or network layer. WinBridge is meant to avoid requiring a second PC for this class of failure.

For cua_node problems it compares the user-local runtime/staging state against resources available from the officially installed Codex package, backs up the current local state, and only stages a replacement when it can verify the source/runtime relationship. It does not download an arbitrary runtime from another user or modify C:\Program Files\WindowsApps in place. The goal is to restore a coherent user-local runtime and keep rollback information.

The two variants reported here are both useful test cases: (1) .staging-* is created but remains empty, and (2) repeated staging directories contain manifest.json/bin but never converge to one completed runtime. If the official installed package itself lacks the required runtime, WinBridge should stop and report that as an upstream/package problem rather than inventing files.

If anyone here tries WinBridge instead of copying cua_node from a second PC, please report the outcome at https://github.com/zemeng5208/winbridge-recovery/issues/4. Even a one-line ✅ worked / 🟡 partial / ❌ no change report would help establish whether this staging failure is reliably recoverable.