[Windows] 26.901.1978.0 fails to launch UI when cua_node staging cannot copy node_repl.exe #42501

Summary

After updating the Microsoft Store Codex Windows app to 26.901.1978.0, Codex launched several ChatGPT.exe processes but never created a visible window. All processes were responsive, but MainWindowHandle remained 0.

Investigation showed that the new bundled cua_node runtime repeatedly failed during staging. Each launch created a new incomplete .staging-ad3b5049246cde44-* directory. The incomplete staging directories contained node.exe but were consistently missing node_repl.exe.

Manually staging the current package's app\resources\cua_node using xcopy /G into the expected versioned runtime directory fixed the problem immediately. Codex then launched normally.

This appears to be another manifestation of the EFS / Application Protected WindowsApps relocation issue reported in #32732 and #25220, but in this build the failure blocks the entire Codex UI from appearing.

Environment

• Codex package: OpenAI.Codex_26.901.1978.0_x64__2p2nqsd0c76g0
• Platform: Windows x64
• Install type: Microsoft Store / MSIX
• Runtime root: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

Symptoms

Immediately after attempting to launch Codex:

Id    ProcessName  Responding  MainWindowHandle
2396  ChatGPT      True        0
25444 ChatGPT      True        0
33412 ChatGPT      True        0
33576 ChatGPT      True        0
35452 ChatGPT      True        0

The startup log stopped after:

2026-09-03T09:31:33.374Z info [sparkle] in_app_updates_policy_wait_started timeoutMs=300000
2026-09-03T09:31:33.375Z info Launching app agentRunId=null allowDebugMenu=false allowDevtools=false allowInspectElement=false buildFlavor=prod enableSparkle=false enableUpdater=true nodeEnv=undefined packaged=true platform=win32
2026-09-03T09:31:33.581Z info Appshot hotkey inactive configured=true enabled=false platform=win32

No main window appeared.

Runtime staging evidence

The runtime directory contained three failed staging attempts plus an older complete runtime:

Name                              Files  NodeExe  NodeRepl
.staging-ad3b5049246cde44-VWwnnl  2542   True     False
.staging-ad3b5049246cde44-xBEXDT  3052   True     False
.staging-ad3b5049246cde44-YJEcC5  2119   True     False
415ffebf3d576e9b                  4679   True     True

After deleting the failed staging directories and launching Codex again, a new failed directory immediately appeared:

.staging-ad3b5049246cde44-co8bps
415ffebf3d576e9b

This confirms the current build expected runtime hash ad3b5049246cde44 and repeatedly failed to finish materializing it.

PowerShell Remove-Item -Recurse -Force also failed while traversing very deep paths under the incomplete staging trees, e.g. node_modules\@oai\sky\dist\js-dependency-cache\...\pnpm-store\..., requiring long-path-aware removal.

Workaround that fixed the launch

With all ChatGPT.exe processes stopped, the current package runtime was copied manually:

$pkg = Get-AppxPackage OpenAI.Codex
$src = Join-Path $pkg.InstallLocation "app\resources\cua_node"
$dst = "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node\ad3b5049246cde44"

New-Item -ItemType Directory -Force -Path $dst | Out-Null
cmd /c xcopy "$src\*" "$dst\" /E /I /H /Y /G

Verification after the copy:

Test-Path "$dst\bin\node.exe"       => True
Test-Path "$dst\bin\node_repl.exe"  => True
File count                            => 4683

After this, Codex launched successfully and the UI appeared normally.

Expected behavior

Codex should successfully materialize the bundled cua_node runtime from the protected Microsoft Store package during an update, without requiring manual copying.

If normal copy semantics fail for Application Protected/EFS resources, the Windows relocation implementation should use an equivalent of COPY_FILE_ALLOW_DECRYPTED_DESTINATION (the behavior that makes xcopy /G work), or another supported stream-copy mechanism.

The app should also detect an incomplete staging runtime and surface the underlying relocation error instead of leaving several responsive background processes with no UI.

Why this is particularly disruptive

The runtime hash changes when Codex updates. Therefore, a previously complete runtime such as 415ffebf3d576e9b does not prevent the problem when a newer build expects ad3b5049246cde44. If the protected-file relocation bug persists, the failure can recur on every update that introduces a new cua_node runtime.

Related

• [Windows] Codex 26.707 cannot stage Browser runtime from EFS-protected WindowsApps files #32732 — Windows Codex cannot stage Browser runtime from EFS-protected WindowsApps files
• [Windows] Bundled plugins (Computer Use, Browser, Chrome, LaTeX) unavailable — copyfile fails on EFS-encrypted WindowsApps files #25220 — bundled plugin copyfile failures on EFS-encrypted WindowsApps files
• [Windows][WSL] MSIX EFS-encrypted bundled codex fails relocation with ERROR_ENCRYPTION_FAILED (0x80071770) #38696 — related MSIX EFS relocation failure for WSL executables