[Windows][26.825.5331.0] Headless startup caused by Application Protected node_repl.exe relocation failure (0x80071770)

What version of the Codex App are you using?

Microsoft Store / MSIX package:

• OpenAI.Codex 26.825.5331.0
• The same headless-startup behavior was also reproduced on 26.825.4187.0 before updating.
• Standalone CLI available at %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe (codex-cli 0.150.1).

What issue are you seeing?

Codex/ChatGPT Desktop starts several background processes but never creates a visible window.

Observed process state:

• main ChatGPT.exe: running, high CPU, MainWindowHandle=0
• crashpad: present
• GPU process: present
• network service: present
• storage service: present
• ChatGPT.exe --type=renderer: missing
• codex.exe app-server: missing

The desktop log stops after only:

Launching app ... enableSparkle=false enableUpdater=false ...
Appshot hotkey inactive configured=true enabled=false platform=win32

Resetting/reinstalling the app, using a standalone CLI via CODEX_CLI_PATH, disabling the updater, and resetting the Electron profile did not fix the issue.

Root cause found

The per-user CUA runtime was stuck in a staging directory such as:

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

Inside that staging directory, bin\node.exe existed and ran successfully:

v24.19.0

but bin\node_repl.exe was missing.

The packaged source file exists at:

C:\Program Files\WindowsApps\OpenAI.Codex_26.825.5331.0_x64__2p2nqsd0c76g0\app\resources\cua_node\bin\node_repl.exe

cipher /c reports:

E node_repl.exe
  Compatibility Level:
    Application Protected

A normal PowerShell copy fails reproducibly:

Copy-Item $src $dst -Force

with:

The specified file could not be encrypted.
HRESULT: 0x80071770

So the CUA runtime relocation never finishes, leaving the app in a headless startup state before the Codex app-server and renderer are created.

Confirmed workaround

Only the missing node_repl.exe was copied into the existing staging directory using Windows xcopy /G (allow decrypted destination):

cmd /c "xcopy \"$src\" \"$dst\" /Y /G"

Result:

1 File(s) copied

After that single-file copy, launching the app immediately succeeded.

The expected processes then appeared:

codex.exe ... app-server
ChatGPT.exe --type=renderer

and the desktop window opened normally. Closing and reopening the app also worked.

Why this looks actionable

This is not only a generic bundled-CLI relocation failure. In this case:

1. CODEX_CLI_PATH already pointed to a working standalone CLI.
2. The app still stayed headless because cua_node relocation was incomplete.
3. The failure was isolated to an Application Protected packaged runtime file (node_repl.exe).
4. A decrypted-destination copy of that one file was sufficient to unblock runtime finalization and the entire desktop startup chain.

Expected behavior

When relocating MSIX/Application Protected runtime resources from WindowsApps into %LOCALAPPDATA%, the desktop app should use a Windows-compatible copy path that allows a decrypted destination (for example behavior equivalent to COPY_FILE_ALLOW_DECRYPTED_DESTINATION) or fall back to buffered read/write.

It should also surface the underlying relocation failure instead of silently remaining headless with only Launching app / Appshot hotkey inactive in the log.

Related issues

• #40843 — bundled executable relocation fails with ERROR_ENCRYPTION_FAILED (0x80071770)
• #38696 — WSL relocation variant of the same protected-file problem
• #25220 — bundled plugin copy failures from EFS/Application Protected WindowsApps files

This report is specifically about the cua_node runtime and node_repl.exe causing full desktop headless startup on 26.825.5331.0.

Start by tracing the CUA runtime relocation involving %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node and the packaged app\resources\cua_node\bin\node_repl.exe, then follow the desktop launch path that creates app-server and the renderer. Reproduce the protected-file copy failure and verify that relocation completes, the underlying error is surfaced, and the desktop window starts normally.