Codex Desktop exits after 26.609/26.611 updates due to cua_node runtime staging/finalization issue

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

• #27780
• #27722
• #27506
• #27546
• #27707

Powered by Codex Action

[Fixed] Codex Windows GUI crashes immediately after launch (June 2026 Update)

Symptom
After the recent automatic update (around version 26.609.xxxx), the Codex Windows GUI application started crashing immediately (within 5-10 seconds) after launch.
While the CLI version (codex.cmd) works perfectly, the GUI completely fails to open.

Under the hood, a crash loop was occurring, continuously creating empty .staging-* directories under AppData\Local\OpenAI\Codex\runtimes\cua_node.

Root Cause
This is due to a mismatch in the expected runtime directory structure introduced in the latest update.
The updated Codex GUI looks for the node runtime inside a new hashed subfolder, but the actual update deployment leaves the runtime files in the old flat directory layout.

Where GUI expects the runtime: ...\cua_node\789504f803e82e2b\manifest.json

Actual layout after update: ...\cua_node\manifest.json

As a result, Codex attempts to unpack the environment into a staging folder on every launch, fails to complete it, and encounters an unhandled C++ exception (0xE06D7363) which kills the process.

Workaround / Solution
You can easily fix this by pre-creating the directory structure that the GUI expects and copying the existing runtime files into it.

Option 1: Fix via PowerShell (Recommended)
Open Task Manager and kill any remaining Codex or node processes.

Open a standard PowerShell window, paste the following script, and hit Enter:

1. Define paths

$base = "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node"
$hash = "789504f803e82e2b" # The specific hash directory expected by the update
$target = Join-Path $base $hash

2. Create directory and copy layout

1. Define paths

$base = "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node"
$hash = "789504f803e82e2b" # The specific hash directory expected by the update
$target = Join-Path $base $hash

2. Create directory and copy layout

if (-not (Test-Path -LiteralPath $target)) {
    New-Item -ItemType Directory -Path $target -Force | Out-Null
    
    # Mirror manifest and bin into the new subfolder
    Copy-Item -LiteralPath (Join-Path $base "manifest.json") -Destination (Join-Path $target "manifest.json") -Force
    Copy-Item -LiteralPath (Join-Path $base "bin") -Destination (Join-Path $target "bin") -Recurse -Force
    
    Write-Host "Success: Directory created and runtime layout mirrored successfully."
} else {
    Write-Host "Target folder already exists."
}

Launch the Codex GUI as usual. It should now successfully finish the handshake and stay open!

Option 2: Fix Manually via File Explorer
If you prefer not to use PowerShell, you can manually arrange the folders using File Explorer to look like this:

AppData\Local\OpenAI\Codex\runtimes\cua_node\
├── bin/ (Original)
├── manifest.json (Original)
└── 789504f803e82e2b/ <-- [Create this new folder]
├── bin/ <-- [Copy the original 'bin' folder here]
└── manifest.json <-- [Copy the original 'manifest.json' here]

Once the files are in place, the application server connection will succeed instantly (next=connected) without triggering the broken staging loop.

Thanks for the mention, @syj07332.
Indeed, my Windows account uses a non-ASCII username (C:\Users\日本語の名前), and I noticed character encoding issues in the Codex CLI logs as well.
Now that I've bypassed the initial startup crash using the runtime folder workaround, I'll keep an eye out to see if this Browser Annotation crash (#28156) triggers on my end. This definitely seems like a crucial piece of the puzzle for non-ASCII users!

Update: this issue reproduced again after updating to Codex Desktop 26.611.8604.0.

After the update, Codex Desktop started exiting shortly after launch again.

The previous workaround directory still existed:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\789504f803e82e2b

However, the new version appeared to expect a different runtime hash. Codex was creating new empty staging directories such as:

.staging-a89897d3d9baa117-...

but there was no finalized runtime directory named:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117

I copied the bundled cua_node runtime from the currently installed package:

C:\Program Files\WindowsApps\OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0\app\resources\cua_node

to:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117

Specifically, I copied:

manifest.json
bin

into the new a89897d3d9baa117 folder.

After doing that, Codex Desktop launched successfully again.

The copied manifest.json contains:

runtime_archive_version: 0.0.1/20260609232601-73ffe8b8261e

The bundled Node runtime also matched the expected version:

v24.14.0

This suggests the issue is not limited to the previous 789504f803e82e2b runtime hash. It appears to recur when a new Codex Desktop update expects a new cua_node runtime hash, but the app fails to finalize the corresponding runtime directory under %LOCALAPPDATA%.

In short, the startup crash returned on 26.611.8604.0, and manually creating the new expected runtime hash folder a89897d3d9baa117 and copying the current package’s resources\cua_node\manifest.json and resources\cua_node\bin fixed the crash again.

Additional note: I was able to use Codex CLI to apply the workaround.

I asked Codex CLI to detect the latest .staging-<hash>-... folder under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

Then it created the matching final runtime folder:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>

and copied the required runtime files from the currently installed Codex package:

Get-AppxPackage OpenAI.Codex
InstallLocation\app\resources\cua_node

Specifically, it copied:

manifest.json
bin

After verifying:

<target>\bin\node.exe --version

against the node_version in manifest.json, Codex Desktop launched successfully.

Important: I explicitly told Codex CLI not to delete existing runtime folders or .staging-* directories.

This suggests the workaround is not tied to a specific hash such as 789504f803e82e2b or a89897d3d9baa117. The practical fix is to detect the latest failed staging hash and manually create the corresponding finalized runtime directory using the bundled resources\cua_node from the currently installed package.

This issue appears related to a cua_node staging/finalization failure I reproduced on a later Codex Desktop build (26.727.6591.0). The app stayed open in my case, but Computer Use returned:

Windows Computer Use Sky runtime is unavailable

The important finding was that runtime contents and runtime directory identity must be validated together. Current runtime files had first been copied under the stale directory ID 03b1cdac8af3a530, while the installed bundle computed the expected ID fb8898c05a62885e from manifest.json, bin/node.exe, and bin/node_repl.exe. Correct files under the wrong content-addressed path were still unusable.

The Microsoft Store WindowsApps source also required a decryption-aware relocation. The repair that worked was:

1. compute the expected runtime ID from the current bundle;
2. copy to a new staging directory with xcopy /G when no matching decrypted local donor exists;
3. verify the three critical SHA-256 hashes;
4. move the validated staging directory to %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<expected-id>;
5. fully restart Codex and test in a new task.

The end-to-end Notepad test then succeeded. A diagnostic-first Skill and non-destructive script are available here:
https://github.com/wwwu379-dot/codex-windows-computer-use-repair

The script preserves existing runtime directories, stops rather than overwriting a conflicting target, and does not change WindowsApps permissions or patch the application.