[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:

CODEX_CLI_PATH already pointed to a working standalone CLI.
The app still stayed headless because cua_node relocation was incomplete.
The failure was isolated to an Application Protected packaged runtime file (node_repl.exe).
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

[Windows][MSIX 26.820.7780.0] App cannot start after auto-update: bundled codex.exe relocation fails with ERROR_ENCRYPTION_FAILED (Unable to locate the Codex CLI binary) #40843 — bundled executable relocation fails with ERROR_ENCRYPTION_FAILED (0x80071770)
[Windows][WSL] MSIX EFS-encrypted bundled codex fails relocation with ERROR_ENCRYPTION_FAILED (0x80071770) #38696 — WSL relocation variant of the same protected-file problem
[Windows] Bundled plugins (Computer Use, Browser, Chrome, LaTeX) unavailable — copyfile fails on EFS-encrypted WindowsApps files #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.

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

[Windows][MSIX 26.820.7780.0] App cannot start after auto-update: bundled codex.exe relocation fails with ERROR_ENCRYPTION_FAILED (Unable to locate the Codex CLI binary) #40843
Windows app launches background Electron processes but never spawns codex.exe or creates a window #41125
[Windows 26.820.9563.0] Desktop remains headless after external Codex CLI workaround #41059

Powered by Codex Action

Thanks for documenting the node_repl.exe case so precisely. I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

This report is directly within the local Windows repair/diagnostic scope WinBridge is intended to cover: CUA runtime relocation/materialization, especially an incomplete %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-* tree where node.exe is present but node_repl.exe is missing, and Application Protected / EFS copy failures from the MSIX WindowsApps source. It can help inspect stale/partial staging, compare the expected runtime/version/hash state, distinguish ordinary file-lock/path problems from ERROR_ENCRYPTION_FAILED (0x80071770), and recover the user-side materialized runtime when that local state is repairable.

The important limitation here is that WinBridge does not modify WindowsApps, take ownership of package files, or bypass Application Protected/EFS. Your xcopy /G result strongly indicates the underlying product bug is still Codex's relocation copy path: if a clean launch continues to recreate a staging tree and the current Desktop build again fails copying the protected node_repl.exe, a durable fix needs to be made upstream (for example, a decrypted-destination-capable copy/fallback in the relocation implementation). WinBridge can diagnose/recover the local cache side, but I would not expect it to guarantee a permanent fix against that upstream behavior.

Additional confirmation from the affected machine:

cipher /c ...\app\resources\cua_node\bin\node_repl.exe

E node_repl.exe
  Compatibility Level:
    Application Protected

A normal PowerShell copy fails consistently:

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

The per-user runtime was stuck at:

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

node.exe was present and runnable (v24.19.0), but node_repl.exe was missing.

Copying only that missing file with:

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

produced:

1 File(s) copied

After that, the app immediately created both:

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

and the desktop window opened. A subsequent close/relaunch also succeeded. This strongly suggests the startup block was the incomplete cua_node relocation caused by the protected node_repl.exe copy failure.

I can reproduce this on the same Microsoft Store build, with a repeatable update/cache pattern.

Environment:

Windows 11 Pro, build 26200, x64
Microsoft Store package OpenAI.Codex
Package stored on a secondary AppxVolume (D:\WindowsApps); Windows exposes the individual package through its managed junction under C:\Program Files\WindowsApps
No npm Codex installation, CODEX_CLI_PATH override, manual WindowsApps changes, Reset, or cache deletion

Measured results:

26.825.4187.0: first launch after update reported startupElapsedMs=576074 (about 9m 36s internally; about 9m 38s from process start to window readiness).
Warm-cache launches of the same version completed in about 7.0-7.5 seconds.
26.825.5331.0: first launch after update reported startupElapsedMs=570182 (about 9m 30s).
For 26.825.5331.0, creation of %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\426e88130fe66c7e spanned about 9m 19s: 4,680 files totaling 334,374,038 bytes.
A shell-environment timer configured for 5,000 ms did not complete until durationMs=566619, consistent with the main process being blocked during runtime preparation.
The CLI handshake then succeeded in 599 ms and the window appeared. No Unable to locate the Codex CLI binary message occurred on that launch.
After startup completed, the previous runtime and CLI caches were removed automatically, so this is not caused by old caches accumulating.

The packaged runtime files are reported as Encrypted / Application Protected. In an earlier controlled test against package 26.820.9563.0, Node copyFileSync failed with UNKNOWN / errno -4094 and native CopyFileW returned error 6000 (The specified file could not be encrypted); buffered read/write succeeded with matching SHA-256. The physical source and test destination were both on D:, so crossing drives was not required to reproduce the copy failure.

Inspection of the bundled 26.825.5331.0 startup code found a synchronous recursive copy path that attempts copyFileSync and falls back to buffered read/write for error 6000 or UNKNOWN / -4094. The fallback eventually succeeds here, but processing thousands of files synchronously delays window creation by roughly 9-10 minutes after each update that changes the runtime cache ID.

No local workaround was applied. The completed cache makes subsequent launches fast, but the delay recurs when an update changes the bundled runtime.

环境信息

操作系统： Windows 11 家庭中文版，64 位
Windows Build： 26200
安装方式： Microsoft Store / MSIX
应用包名： OpenAI.Codex
受影响版本：
- 26.825.5331.0
- 回退到 26.820.10647.0 后仍可复现
standalone Codex CLI： codex-cli 0.151.0

问题现象

启动 ChatGPT 后没有窗口，但任务管理器中可以看到多个 ChatGPT.exe 进程在后台运行：

MainWindowHandle: 0
MainWindowTitle: 空
Responding: True

进程树中存在以下基础进程：

ChatGPT.exe
ChatGPT.exe --type=crashpad-handler
ChatGPT.exe --type=gpu-process
ChatGPT.exe --type=utility --utility-sub-type=network.mojom.NetworkService
ChatGPT.exe --type=utility --utility-sub-type=storage.mojom.StorageService

异常现象：

始终没有出现 ChatGPT.exe --type=renderer
主进程从未拉起 codex.exe app-server

Runtime 检查

MSIX 安装目录下的源文件：
C:\Program Files\WindowsApps\OpenAI.Codex_26.820.10647.0_x64__2p2nqsd0c76g0\app\resources\cua_node\bin\node_repl.exe

文件属性显示：Archive, Encrypted（受应用保护/EFS加密）。

用户本地暂存目录（%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-*\bin\）状态：

node.exe: 存在
node_repl.exe: 缺失

使用普通 PowerShell 复制该文件时失败，报错：
The specified file could not be encrypted. HRESULT: 0x80071770

临时处理与启动观察

使用 xcopy /G 强制解密并复制缺失文件：

$p = Get-AppxPackage -Name OpenAI.Codex
$src = Join-Path $p.InstallLocation 'app\resources\cua_node\bin\node_repl.exe'

$root = Join-Path $env:LOCALAPPDATA 'OpenAI\Codex\runtimes\cua_node'
$d = Get-ChildItem $root -Directory -Force |
      Where-Object { $_.Name -like '.staging-*' } |
      Sort-Object LastWriteTime -Descending |
      Select-Object -First 1

$dst = Join-Path $d.FullName 'bin'

xcopy.exe $src $dst /Y /G /I

命令返回：1 File(s) copied。

关键观察： 补全单个文件后并没有立刻弹出界面。应用主进程在后台继续运行并持续准备剩余 runtime 文件（观察到文件数随时间递增：约 90 秒 851 个、210 秒 1434 个、360 秒 2145 个）。

当整个 runtime 彻底解压/准备完成后，ChatGPT Desktop 成功打开：

MainWindowHandle: 恢复正常数值
MainWindowTitle: ChatGPT
ChatGPT.exe --type=renderer 正常出现
主进程正常拉起 codex.exe ... app-server ...

期望行为

文件 I/O 兼容性： 正确处理 MSIX 中受保护/加密文件的解包与复制，避免因标准文件流写入失败导致中断。
异常处理： 在解包异常时提供错误日志或降级策略，避免无限期处于无界面的 headless 状态。
加载进度感知： 若初次初始化需要解压上千个文件且耗时数分钟，建议提供 SplashScreen 或前台加载提示。

Additional reproduction from Windows 10 / OpenAI.Codex 26.825.5331.0:

Main ChatGPT.exe process stays Responding=True with MainWindowHandle=0.
Each launch creates a new %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node.staging-426e88130fe66c7e-* directory.
Every newly created staging directory contains bin\node.exe but is missing bin\node_repl.exe.
cipher /c on the packaged source confirms node_repl.exe is Application Protected.
Copying the missing file into the latest staging directory with xcopy /G succeeds.
However, after restarting the app, Codex creates another new staging directory and again fails to copy node_repl.exe, so the single-file workaround is not persistent on this machine.
In one repaired staging directory, source runtime had 4,680 files / 334,374,038 bytes, while the staging directory contained only 3,762 files / 298,985,498 bytes, suggesting relocation aborts before the runtime is fully committed.

This may indicate that the relocation failure causes the whole staging transaction to be abandoned, so repairing only the currently failed staging directory does not necessarily prevent the next launch from repeating the same failure.

The UX impact is severe: the app silently runs headless for many minutes with no window or visible error, and users may repeatedly kill/relaunch it, creating more stale staging directories.

[Written by ChatGPT after our discussion about how to handle my real trouble now]

After leaving the app running, the staging directory was eventually committed successfully as 426e88130fe66c7e with all 4,680 files / 334,374,038 bytes, and the GUI opened. So in this case the relocation eventually completed, but only after a long headless startup and several abandoned staging directories.

I completed a deeper controlled diagnosis on the same affected Microsoft Store
build. This confirms the protected-file copy failure and also identifies why
the app remains headless for several minutes even when the fallback eventually
succeeds. It also explains the delayed-timer evidence reported in #41539.

Exact copy behavior

Environment:

AppX package: OpenAI.Codex 26.825.5331.0
Packaged node_repl.exe: Encrypted; cipher /C reports
Application Protected
CUA runtime: 4,680 files / 334,374,038 bytes

Against the exact packaged node_repl.exe:

Copy method	Result
PowerShell `Copy-Item`	Fails: `0x80071770`, "The specified file could not be encrypted"
`.NET System.IO.File.Copy`	Fails with the same underlying encryption error
Node `fs.copyFileSync`	Fails: `code=UNKNOWN`, `errno=-4094`, `syscall=copyfile`
Plain `xcopy`	Fails with the Windows encryption error
`xcopy /G`	Succeeds
Node read stream -> ordinary write stream	Succeeds; SHA-256 matches the source

This is the same Windows failure represented as ERROR_ENCRYPTION_FAILED /
Win32 error 6000, HRESULT 0x80071770, or Node/libuv UNKNOWN/-4094. It is a
protected-copy semantic issue, not a missing packaged file, GPU failure, or
renderer crash.

Owning package and startup implementation

Read-only inspection of the installed app.asar identifies the owner as:

npm package: openai-codex-electron
package version: 26.825.41651
build: 7345
CUA relocation chunk: .vite/build/src-4lLVrYxe.js
shared copy-helper chunk: .vite/build/windows-file-copy-Dm31CRG0.js

The CUA relocation path recursively traverses and copies the runtime
synchronously in the Electron main process. It attempts copyFileSync, then
uses synchronous read/write fallback for error 6000 or UNKNOWN/-4094. The
fallback can therefore finish, but synchronously processing approximately
4,680 protected files / 334 MB blocks window creation, renderer startup,
app-server startup, and all main-loop timers.

One captured launch provides direct event-loop evidence:

A shell-environment operation configured for 5,000 ms reported
durationMs=318335.
The 300,000 ms updater-policy timer fired at the same instant the event
loop resumed.
startupElapsedMs=328061.

A pending 5-second timer cannot fire 318 seconds late unless the main event
loop is occupied. This explains the responsive process with
MainWindowHandle=0, no renderer, and no crash.

The installed implementation also has only a process-local Map; there is no
cross-process lock keyed by runtime hash. Repeated launches can therefore
populate separate .staging-* trees concurrently and duplicate the full copy
before any promotion race is resolved.

Validation gap

The runtime validator hashes only:

manifest.json
bin/node.exe
bin/node_repl.exe

For bin/node_modules, it checks only that the directory exists.

A manually materialized runtime containing 4,679 of 4,680 files was accepted
as valid even though a 323-character destination path ending in
node_modules/tslib/tslib.es6.js was missing. After adding that file using
exclusive-create stream copying, a complete comparison produced:

sourceFiles=4680
finalFiles=4680
sourceBytes=334374038
finalBytes=334374038
checked=4680
pathDiffCount=0
contentDiffCount=0

All relative paths and every per-file SHA-256 digest now match.
node.exe --version returns v24.19.0, node_repl.exe --help exits 0, and the
desktop window, renderer, and codex.exe app-server are responsive. This
verifies the local materialization, but it is only a manual recovery.

Shared helper gap

The separate asynchronous windows-file-copy helper already has a bounded
stream fallback, but its encryption predicate accepts only errno === 6000.
On this Node/Electron build the same copy failure is surfaced as
code=UNKNOWN, errno=-4094, so the helper does not enter its fallback.

Current logs repeatedly show:

plugin_marketplace_folder_write_failed errorCode=UNKNOWN

against Application Protected bundled-plugin files. This left 157
~/.codex/.tmp/bundled-marketplaces/openai-bundled.staging-* roots on the
affected machine, indicating the error-mapping gap affects plugin
materialization as well as CUA startup.

Suggested maintainer fix

Centralize an isWindowsEncryptionFailure(error) predicate covering Win32
6000 and Node/libuv UNKNOWN/-4094, with tests for both representations.
Replace the CUA synchronous fallback with the shared asynchronous stream
implementation, or perform all traversal, hashing, and materialization in a
worker process/thread.
Keep CUA hashing/copying off the Electron main event loop; preferably defer
optional CUA setup until first use or show a real foreground loading state.
Add a cross-process lock keyed by runtime hash, atomic promotion, stale-lock
recovery, and staging cleanup in finally.
Validate every required relative path, size, and digest rather than treating
an existing node_modules directory as complete.
Test protected files, errno=6000, UNKNOWN/-4094, two-process races,
interrupted staging, incomplete final runtimes, promotion collisions, paths
longer than MAX_PATH, and timer responsiveness during a cold install.

Limit: this diagnosis comes from controlled local reproduction, desktop logs,
and read-only inspection of the installed bundle. The private
openai-codex-electron source repository and a buildable desktop checkout are
not available to this GitHub account, so I cannot provide a source PR or
fixed-build test results. The public openai/codex repository does not contain
this Electron/MSIX materialization implementation.

Confirmed on Windows Codex Desktop 26.825.6671.0.

I reproduced the same cua_node runtime relocation/staging failure. Every launch created a new .staging-* directory. In the failed staging directories, bin\node.exe was present but bin\node_repl.exe was missing, and one comparison against the packaged runtime showed approximately 4,610 missing downstream files.

Copying only node_repl.exe was not sufficient because the next launch created a new staging directory and failed again.

The workaround that consistently restored Codex was to copy the entire packaged app\resources\cua_node runtime using decrypted-destination semantics (xcopy /G) into the correct content-addressed runtime directory:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\415ffebf3d576e9b

After verifying the destination file set was complete, Codex Desktop opened normally.

This confirms the issue is still reproducible in 26.825.6671.0.

Additional confirmation on OpenAI.Codex 26.825.6671.0 (Windows 11 x64, Microsoft Store/MSIX), with a slightly different failure mode from the single-file workaround described above.

Observed behavior

Launching the desktop app created multiple background ChatGPT.exe processes, but no visible window.
AppX/AppModel activation succeeded; the failure was later in startup.
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node accumulated a new .staging-415ffebf3d576e9b-* directory on every launch.
The expected final runtime directory 415ffebf3d576e9b was never created.
In each failed staging directory, bin\node.exe existed while bin\node_repl.exe was missing.

The packaged source file existed under the MSIX package at app\resources\cua_node\bin\node_repl.exe.

Single-file workaround was insufficient on 26.825.6671.0

Using xcopy /G to copy only node_repl.exe into the latest staging directory succeeded (Test-Path became True), but the next launch created a new staging directory and failed again.

This suggests the staging copy had aborted early and was missing substantially more than just node_repl.exe.

Workaround that restored the app

I stopped all ChatGPT.exe processes, then copied the entire packaged app\resources\cua_node runtime with xcopy /G directly into the content-addressed destination:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\415ffebf3d576e9b

The copy completed with 4679 files. Validation afterwards showed:

bin\node.exe = present
bin\node_repl.exe = present
manifest.json = present
source file count = 4679
destination file count = 4679
missing files = 0
extra files = 0

After that, the ChatGPT/Codex desktop window opened normally.

Likely implication

For 26.825.6671.0, the Application Protected/EFS relocation problem can abort the full cua_node directory materialization, and failed staging is not recovered on the next launch. A single-file repair may therefore not be sufficient; pre-populating the complete content-addressed runtime with a decrypted-destination-capable copy path (xcopy /G) restored startup.

It would be useful to check whether the current Windows relocation fallback handles ERROR_ENCRYPTION_FAILED / Win32 6000 for all files in the recursive copy path, and whether an incomplete .staging-* tree can be resumed or validated atomically instead of silently abandoned and recreated on every launch.

Additional read-only static analysis from an affected Windows machine running OpenAI.Codex 26.825.6671.0 with cua_node runtime id 415ffebf3d576e9b.

I inspected the installed app.asar only; no files under WindowsApps or %LOCALAPPDATA% were modified during this analysis. The Desktop code is minified and there is no usable source map, so the names below are recovered from the bundled JS.

Bundled relocation path recovered from `app.asar`

Relevant bundle files:

.vite/build/src-C2ILPx7g.js
.vite/build/main-BP8-d4nf.js
.vite/build/windows-file-copy-Dm31CRG0.js

For CUA runtime relocation, the recovered call chain is approximately:

pI()/mI() -> CI() -> TI()

pI() resolves node_repl.exe; mI() resolves node.exe. When the source is under WindowsApps, TI() materializes the runtime under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

using a .staging-<runtime-id>-<random> directory, then promotes it to the final content-addressed directory.

Important finding: 26.825.6671.0 does contain a buffered fallback

The CUA copy helper recovered from the bundle is equivalent to:

function EI(source, destination) {
  try {
    fs.copyFileSync(source, destination)
  } catch (error) {
    if (
      !(error instanceof Error) ||
      !("errno" in error) ||
      (
        error.errno !== 6000 &&
        (
          error.errno !== -4094 ||
          !("code" in error) ||
          error.code !== "UNKNOWN"
        )
      )
    ) {
      throw error
    }

    fs.writeFileSync(destination, fs.readFileSync(source))
  }
}

So this build explicitly falls back for:

errno == 6000
errno == -4094 && code == "UNKNOWN"

The fallback is synchronous readFileSync + writeFileSync; it is not streaming, and it does not use a Win32 COPY_FILE_ALLOW_DECRYPTED_DESTINATION path.

Directory-copy behavior

The recursive copy helper is equivalent to:

function DI(sourceRoot, destinationRoot) {
  fs.mkdirSync(destinationRoot, { recursive: true })

  for (const entry of fs.readdirSync(sourceRoot, { withFileTypes: true })) {
    const source = join(sourceRoot, entry.name)
    const destination = join(destinationRoot, entry.name)

    if (entry.isDirectory()) {
      DI(source, destination)
      continue
    }

    EI(source, destination)
  }
}

Implications:

synchronous, recursive, per-file copy;
no checkpoint / resume state;
no skip-on-error;
any unhandled failure in copy/read/write/mkdir/readdir/etc. aborts the entire tree copy immediately.

This matches the observed incomplete staging shape on the affected machine: node.exe present, node_repl.exe absent, and thousands of later files never materialized.

However, because 6000 and -4094/UNKNOWN are already handled by EI(), the exact final escaping exception for this incident is still unknown. The old Desktop/Sentry logs for the 22:05-22:35 failure window are no longer retained locally, so I cannot honestly claim whether the escaping error was the copyFileSync error shape itself, the buffered fallback, another fs operation, or process termination.

Runtime id / finalize / reuse behavior

For this build, the runtime id is derived from only:

manifest.json
bin/node.exe
bin/node_repl.exe

The affected machine computes:

415ffebf3d576e9b

The materialization flow is:

compute key-file hash
-> check final runtime dir
-> create .staging-<hash>-XXXXXX
-> recursively copy full tree
-> renameSync(staging, final)

The on-disk reuse validation checks only:

manifest.json      exists + expected size/hash
bin/node.exe       exists + expected size/hash
bin/node_repl.exe  exists + expected size/hash
bin/node_modules   is a directory

It does not validate:

complete file count;
complete relative path set;
all remaining runtime files;
a full tree hash/manifest.

There is also no staging resume/checkpoint mechanism. Cleanup of stale staging is best-effort and cleanup exceptions are swallowed, so interrupted or failed staging directories can remain and a later launch can create a fresh .staging-* again.

Workaround result on the affected machine

Manually materializing the entire official packaged cua_node tree into:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\415ffebf3d576e9b

with xcopy /G copied 4679 files. A subsequent file-set comparison reported:

Source files : 4679
Target files : 4679
Missing      : 0
Extra        : 0

and manifest.json, bin/node.exe, and bin/node_repl.exe were all present.

After that, the Desktop app opened normally immediately. This strongly narrows the failure to:

WindowsApps protected source
-> cua_node relocation / fallback
-> staging completion / finalize

rather than AppX activation, GPU, window placement, or a broken runtime payload.

Suggested maintainer focus

The strongest follow-up questions from this build are:

Why can the CUA relocation still leave an incomplete staging tree when 6000 and -4094/UNKNOWN already have a buffered fallback?
Can the escaping error be normalized/logged with the exact relative file path and original Win32/HRESULT value?
Should the Windows path use a decrypted-destination-capable native copy path (or a single reliable streaming fallback) instead of depending on exact Node error-shape matching?
Can failed staging be resumed/validated instead of always creating a new one?
Should final runtime reuse verify the full runtime tree, not only three key files plus the node_modules directory?

This is consistent with the user-visible failure pattern already reported here, but adds a concrete static view of the 26.825.6671.0 bundled implementation.

Confirmed on a newer Windows MSIX build: Codex Desktop 26.825.6671.0 on Windows 11 10.0.26200 x64.

I reproduced the same headless-startup behavior after updating the Desktop app.

Process state while stuck:

main ChatGPT.exe running
crashpad running
GPU process running
network/storage utility processes running
no ChatGPT.exe --type=renderer
no codex.exe app-server
no visible window

codex doctor reported 0 failures; config, auth, state databases, WebSocket and OpenAI endpoint reachability were all healthy.

Updating the standalone CLI from 0.149.1 to 0.151.0 did not change the Desktop behavior.

I then inspected:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

Every failed launch was creating another directory matching:

.staging-415ffebf3d576e9b-*

The newest staging directories repeatedly had:

bin\node_repl.exe missing

while an older completed runtime (426e88130fe66c7e) contained it normally.

Copying the protected node_repl.exe using xcopy /G succeeded, while simply repairing an already-failed staging instance did not make that existing process resume; subsequent launches could create another fresh incomplete staging directory.

Eventually the new runtime finalized as:

415ffebf3d576e9b

and verification showed:

manifest.json: present
bin\node.exe: present
bin\node_repl.exe: present
node.exe --version: v24.19.0

After the completed runtime existed, Codex Desktop successfully created its window again.

So this appears to confirm that the cua_node protected-file relocation / staging-finalization issue is still reproducible in 26.825.6671.0.

Update: reproduced on a newer Windows Store/MSIX build, 26.825.6671.0

I reproduced the same headless-startup pattern on Windows 11 x64 after the app updated to:

Package: OpenAI.Codex_26.825.6671.0_x64__2p2nqsd0c76g0
App entry point: OpenAI.Codex_2p2nqsd0c76g0!App

After the update, five ChatGPT.exe processes remained running and responsive, but all had no visible window (MainWindowHandle=0 and an empty title). The per-user CUA runtime contained two .staging-* directories under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

One staging directory was still growing while the other was incomplete and stopped progressing. The startup log also recorded:

in_app_updates_policy_wait_started timeoutMs=300000

The app became usable only after I terminated the stale ChatGPT processes, removed only the abandoned .staging-* directories, and launched the AppX entry point once. The runtime then completed with 4,679 files and included node.exe, node_repl.exe, and node_modules; the ChatGPT window appeared and responded normally. I did not modify WindowsApps permissions, package files, or user/chat data.

This newer build appears consistent with the same runtime-relocation/startup coordination problem described in this issue. The per-user staging cache is a symptom; the client should either use a Windows-compatible copy path for Application Protected files, reuse a complete verified runtime, and/or avoid blocking first-window creation during update initialization. It should also surface a recoverable error instead of leaving multiple headless processes.

I found another workaround for this issue on Windows with OpenAI.Codex 26.825.5331.0.

My symptoms matched this report: several ChatGPT.exe processes were running with Responding=True but MainWindowHandle=0, and %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node kept accumulating .staging-426e88130fe66c7e-* directories. An older runtime directory still contained bin\node_repl.exe, while the new staging runtime was not finalizing.

What fixed it for me was using the Windows Settings UI to move the ChatGPT/Codex app to another drive, then move it back to the original drive:

Windows Settings → Apps → Installed apps → ChatGPT/Codex.
Choose Move and move the app to another drive.
After the move completes, use Move again and move it back to the original drive.
Launch the app normally.

After this, the desktop app started normally again. I did not need to manually copy node_repl.exe with xcopy /G.

Before finding this workaround, Repair/Reset/reinstall did not resolve the startup problem, and using a standalone Codex CLI with CODEX_CLI_PATH only got past the earlier bundled CLI problem but did not solve the headless cua_node startup issue.

My guess is that moving the MSIX package causes Windows to redeploy/reprocess the Application Protected package files, which may avoid or repair the problematic relocation state. I can't confirm that mechanism, but the move-away-and-back operation reproducibly restored the app on my machine.

Follow-up: I published an unofficial user-side recovery launcher for this specific Windows/MSIX cua_node relocation failure:

Repository: https://github.com/illionharutome/chatgpt-windows-selfheal
v1.0.0 ZIP snapshot: https://github.com/illionharutome/chatgpt-windows-selfheal/raw/main/dist/ChatGPT-Windows-SelfHeal-v1.0.0.zip
Release notes: https://github.com/illionharutome/chatgpt-windows-selfheal/blob/main/RELEASE_NOTES_v1.0.0.md

It dynamically detects the installed OpenAI.Codex package, computes the current cua_node runtime ID from the shipped runtime files, validates the existing final runtime, and—only when repair is needed—materializes the complete runtime with xcopy /G into a temporary repair directory, validates the copied tree, then promotes it using a same-volume rename. It does not modify WindowsApps ACLs/EFS or hard-code a package version/runtime ID.

One additional data point from the affected machine: the failure reproduced again after later Desktop updates when the runtime ID changed. This reinforces that the workaround fixes the per-version materialized cache, while the underlying relocation path remains vulnerable across updates.

Possible AppxVolume / non-system-drive factor (unconfirmed)

There may also be a correlation worth checking with where the Store/MSIX package is physically stored. A report already in this thread describes the package residing on a secondary AppxVolume (D:\WindowsApps) while Windows exposed the package through the managed path under C:\Program Files\WindowsApps. That configuration also reproduced the Application Protected / ERROR_ENCRYPTION_FAILED behavior.

I do not have enough evidence to claim that installing/moving ChatGPT off C: is the root cause, and the visible InstallLocation alone may be misleading because Windows can surface a managed junction under C:\Program Files\WindowsApps. But it seems worth correlating affected vs unaffected machines by the package's actual AppxVolume / physical backing volume, especially because the failure is in protected-file copy semantics rather than normal app activation.

Useful things to compare across reports:

actual AppxVolume / package backing volume;
whether the package was moved to a secondary drive through Windows/Store settings;
source and %LOCALAPPDATA% destination filesystem/volume;
whether cipher /c reports the affected runtime files as Application Protected;
exact Win32 error returned by the first failing copy and by the buffered fallback.

This is only a hypothesis / correlation target, not a confirmed cause.

Confirmed on Codex Desktop 26.901.1978.0

I can confirm that this issue still reproduces on a newer Microsoft Store/MSIX build.

Environment

Windows 11 Pro x64
Windows build: 10.0.26200
Codex Desktop: 26.901.1978.0
Installation: Microsoft Store/MSIX
Package status: Ok
Previously affected version: 26.825.3734.0

Completely uninstalling and reinstalling the desktop app did not resolve the problem.

Failure symptoms

During the failed launch:

Multiple ChatGPT.exe processes were running.
No visible application window was created.
All processes initially reported MainWindowHandle = 0.
The main process consumed high CPU and approximately 562 MB of working memory.
No completed versioned CUA runtime directory was created.
Every launch created another incomplete staging directory under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-ad3b5049246cde44-*

The packaged runtime contained:

Files: 4,684
Bytes: 337,646,542

Two failed staging attempts contained only:

318 files
1,197 files

The expected completed runtime directory was absent:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ad3b5049246cde44

Application Protected source

Running cipher /C against the packaged cua_node\bin\node.exe reported:

E node.exe
Compatibility Level:
  Application Protected

Workaround

I stopped only the Codex desktop-app processes and copied the complete packaged cua_node runtime into the expected content-addressed runtime directory:

robocopy "<InstallLocation>\app\resources\cua_node" `
  "%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ad3b5049246cde44" `
  /E /COPY:DT /DCOPY:DT /R:1 /W:1

Verification reported:

Directories: 834
Files: 4,684
Bytes: 337,646,542
Failures: 0
Mismatches: 0

After the complete runtime was pre-populated:

The app immediately created a visible window.
MainWindowHandle became nonzero.
The application reported Responding = True.
The abandoned staging directories were automatically removed.
Subsequent launches worked normally.

This confirms that the Application Protected runtime-relocation issue still occurs on 26.901.1978.0.

It also confirms that reinstalling the Microsoft Store app is not a durable fix, because each update can introduce a new content-addressed runtime ID and trigger the same failed relocation process again.

Follow-up: still reproduces on 26.901.1978.0

The same Windows headless-startup issue still reproduces after reinstalling and rebooting.

Environment:

Package: OpenAI.Codex
Version: 26.901.1978.0
Windows build: 26200
Runtime hash: ad3b5049246cde44

Observed:

Multiple ChatGPT.exe processes start.
Main process uses high CPU.
MainWindowHandle = 0.
No visible window appears.
Startup logs stop after:
- Launching app
- Appshot hotkey inactive
Runtime staging directories are repeatedly created under:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-ad3b5049246cde44-*
Staging directories contain bin\node.exe but initially lack bin\node_repl.exe.

Reinstalling, resetting AppX state, resetting Desktop data, disabling GPU, and rebooting did not fix it.

The GUI was restored by copying the complete packaged runtime with xcopy /G:

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

to:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ad3b5049246cde44

The source and destination contained the same 4684 files after copying.

After that:

- ChatGPT.exe --type=renderer appeared.
- Codex codex.exe app-server started.
- The main ChatGPT window appeared.
- Logs reached window main frame finished load and window ready-to-show.

This suggests the runtime relocation/materialization bug remains present in 26.901.1978.0.

I can confirm this issue is still reproducible on a newer Windows build of the ChatGPT/Codex desktop app and, importantly, it can recur after a successful workaround.

Environment:

Windows desktop app package: OpenAI.Codex 26.901.2854.0
Package status: Ok
Symptom: multiple ChatGPT.exe processes start, but every process has MainWindowHandle = 0; no visible window appears.

Observed runtime state under:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

Multiple staging directories were created with the same runtime hash:
.staging-8e7585fc8f35ed57-*

For each affected staging directory:

bin\node.exe existed
bin\node_repl.exe was missing

Checks consistently returned:

NodeExe      = True
NodeReplExe  = False

Repair/reset/reinstall and killing/restarting the app did not fix the problem.

A full runtime copy from the packaged source:
<WindowsApps>\OpenAI.Codex_26.901.2854.0_x64__2p2nqsd0c76g0\app\resources\cua_node

to:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\8e7585fc8f35ed57

using:
xcopy ... /E /I /H /Y /G

copied 4683 files and restored:

node.exe = present
node_repl.exe = present
manifest.json = present

Immediately after this, the desktop app launched normally.

Most importantly: the app worked normally for several days, then the exact same headless startup failure returned. Running the same runtime repair again restored the app immediately.

So this does not appear to be only a one-time migration failure during initial install/update. The per-user cua_node runtime can later fall back into an incomplete staging state and block window creation again.

This recurrence on 26.901.2854.0 suggests the underlying Windows/Application Protected relocation path is still active in current builds and may need both:

a decrypted-destination-compatible copy mechanism, and
validation/reuse of an already complete runtime so a later failed relocation does not regress a previously working installation.

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

Description

What version of the Codex App are you using?

What issue are you seeing?

Root cause found

Confirmed workaround

Why this looks actionable

Expected behavior

Related issues

Activity

github-actions commented on Aug 29, 2026

zemeng5208 commented on Aug 29, 2026

Andu180 commented on Aug 29, 2026

NeonSilver commented on Aug 29, 2026

B0weny-qwq commented on Aug 29, 2026

环境信息

问题现象

Runtime 检查

临时处理与启动观察

期望行为

AladdinGodot commented on Aug 30, 2026

AladdinGodot commented on Aug 30, 2026

anguobao123 commented on Aug 30, 2026

Exact copy behavior

Owning package and startup implementation

Validation gap

Shared helper gap

Suggested maintainer fix

ForrestKang commented on Aug 30, 2026

illionharutome commented on Aug 30, 2026

Observed behavior

Single-file workaround was insufficient on 26.825.6671.0

Workaround that restored the app

Likely implication

illionharutome commented on Aug 30, 2026

Bundled relocation path recovered from app.asar

Important finding: 26.825.6671.0 does contain a buffered fallback

Directory-copy behavior

Runtime id / finalize / reuse behavior

Workaround result on the affected machine

Suggested maintainer focus

Sherlock887 commented on Aug 30, 2026

Orion-FFF commented on Aug 31, 2026

m3101776773-dev commented on Aug 31, 2026

illionharutome commented on Sep 3, 2026

Possible AppxVolume / non-system-drive factor (unconfirmed)

lingwei-zheng commented on Sep 3, 2026

Confirmed on Codex Desktop 26.901.1978.0

Environment

Failure symptoms

Application Protected source

Workaround

Misaka19017 commented on Sep 3, 2026

Follow-up: still reproduces on 26.901.1978.0

tbh67373 commented on Sep 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Bundled relocation path recovered from `app.asar`