Bug report: ChatGPT/Codex Desktop repeatedly fails to start on Windows after auto-update due to `cua_node` runtime relocation

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

OpenAI.Codex 26.825.6671.0

What subscription do you have?

plus

What platform is your computer?

• OS: Windows x64 - Distribution: Microsoft Store / MSIX - Current package: - OpenAI.Codex 26.831.1445.0 - package family: OpenAI.Codex_2p2nqsd0c76g0 - App ID: - OpenAI.Codex_2p2nqsd0c76g0!App - System drive: - NTFS 3.1 - EFS test in the user's temp directory: - cipher /e <temp>\efs-test\test.txt - result: [OK] - so ordinary NTFS/EFS functionality on the system drive is working.

What issue are you seeing?

Bug report: ChatGPT/Codex Desktop repeatedly fails to start on Windows after auto-update due to cua_node runtime relocation

Summary

ChatGPT/Codex Desktop on Windows repeatedly starts headless after Microsoft Store auto-updates. The main ChatGPT.exe, crashpad, GPU and utility processes are created, but ChatGPT.exe --type=renderer and codex.exe ... app-server are missing, and no usable window appears.

The problem reproduced on:

• OpenAI.Codex 26.825.6671.0
• after auto-update, again on OpenAI.Codex 26.831.1445.0

A normal reinstall/reset did not provide a durable fix.

Environment

• OS: Windows x64
• Distribution: Microsoft Store / MSIX
• Current package:
  • OpenAI.Codex 26.831.1445.0
  • package family: OpenAI.Codex_2p2nqsd0c76g0
• App ID:
  • OpenAI.Codex_2p2nqsd0c76g0!App
• System drive:
  • NTFS 3.1
• EFS test in the user's temp directory:
  • cipher /e <temp>\efs-test\test.txt
  • result: [OK]
  • so ordinary NTFS/EFS functionality on the system drive is working.

Symptoms

On launch, Windows AppModel reports successful package activation and process creation.

Observed process state during failure:

• main ChatGPT.exe: present
• crashpad handlers: present
• GPU process: present
• network utility process: present
• storage utility process: present
• ChatGPT.exe --type=renderer: missing
• codex.exe ... app-server: missing
• visible application window: missing / unusable

Disabling the updater did not resolve the issue.

Calling ShowWindow() on discovered Chromium windows also did not restore the UI while the renderer was absent.

Runtime staging failure

Under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

every failed launch created another directory of the form:

.staging-<runtime-id>-<random>

For the earlier affected build, multiple staging directories contained:

• bin\node.exe: present
• bin\node_repl.exe: missing

while the packaged source file existed under:

C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0\app\resources\cua_node\bin\node_repl.exe

More than twenty failed staging directories accumulated across repeated launches.

Confirmed workaround

The reliable workaround was to:

1. identify the runtime ID from the newest .staging-<runtime-id>-* directory;
2. create the final content-addressed runtime directory:
   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>
3. copy the complete official packaged cua_node runtime from WindowsApps into that directory with:
   xcopy /E /I /H /Y /G
4. verify:
   • bin\node.exe
   • bin\node_repl.exe
   • manifest.json
5. relaunch ChatGPT.

In the successful repair on 26.825.6671.0, 4,679 files were copied. Immediately afterward:

• ChatGPT.exe --type=renderer appeared;
• codex.exe ... app-server appeared;
• the desktop window opened and could be closed/reopened normally.

After a Microsoft Store auto-update to 26.831.1445.0, the startup failure returned, indicating the workaround is runtime/version-specific and must be repeated when the content-addressed runtime ID changes.

Why this appears to be a product bug rather than broken local EFS

The system drive is NTFS 3.1, and a local EFS encryption test succeeds:

cipher /e <temp>\efs-test\test.txt → [OK]

The failure is specifically associated with relocation/extraction of packaged Application Protected resources from the MSIX/WindowsApps location into the user-writable runtime cache.

Expected behavior

The desktop app should:

1. reliably relocate/extract bundled Application Protected runtime resources into the user cache;
2. use a Windows copy path that supports a decrypted destination (equivalent to COPY_FILE_ALLOW_DECRYPTED_DESTINATION / xcopy /G) or use a safe buffered read/write fallback;
3. atomically finalize the content-addressed runtime;
4. recover from an incomplete .staging-* directory rather than creating a new failed staging directory on every launch;
5. surface the underlying relocation error instead of silently remaining headless.

Related public reports

• openai/codex #41540 — headless startup caused by Application Protected node_repl.exe relocation failure (0x80071770)
• openai/codex #41654 — repeated regressions across updates due to Application Protected runtime relocation failures
• openai/codex #40843 — MSIX bundled executable relocation fails with ERROR_ENCRYPTION_FAILED
• openai/codex #40791 — Windows startup blocker involving Application Protected codex.exe

Additional note

No WindowsApps ownership/ACLs, package files, registry EFS settings, or system encryption settings were modified to achieve the workaround.

What steps can reproduce the bug?

Bug report: ChatGPT/Codex Desktop repeatedly fails to start on Windows after auto-update due to cua_node runtime relocation

Summary

ChatGPT/Codex Desktop on Windows repeatedly starts headless after Microsoft Store auto-updates. The main ChatGPT.exe, crashpad, GPU and utility processes are created, but ChatGPT.exe --type=renderer and codex.exe ... app-server are missing, and no usable window appears.

The problem reproduced on:

• OpenAI.Codex 26.825.6671.0
• after auto-update, again on OpenAI.Codex 26.831.1445.0

A normal reinstall/reset did not provide a durable fix.

Environment

• OS: Windows x64
• Distribution: Microsoft Store / MSIX
• Current package:
  • OpenAI.Codex 26.831.1445.0
  • package family: OpenAI.Codex_2p2nqsd0c76g0
• App ID:
  • OpenAI.Codex_2p2nqsd0c76g0!App
• System drive:
  • NTFS 3.1
• EFS test in the user's temp directory:
  • cipher /e <temp>\efs-test\test.txt
  • result: [OK]
  • so ordinary NTFS/EFS functionality on the system drive is working.

Symptoms

On launch, Windows AppModel reports successful package activation and process creation.

Observed process state during failure:

• main ChatGPT.exe: present
• crashpad handlers: present
• GPU process: present
• network utility process: present
• storage utility process: present
• ChatGPT.exe --type=renderer: missing
• codex.exe ... app-server: missing
• visible application window: missing / unusable

Disabling the updater did not resolve the issue.

Calling ShowWindow() on discovered Chromium windows also did not restore the UI while the renderer was absent.

Runtime staging failure

Under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

every failed launch created another directory of the form:

.staging-<runtime-id>-<random>

For the earlier affected build, multiple staging directories contained:

• bin\node.exe: present
• bin\node_repl.exe: missing

while the packaged source file existed under:

C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0\app\resources\cua_node\bin\node_repl.exe

More than twenty failed staging directories accumulated across repeated launches.

Confirmed workaround

The reliable workaround was to:

1. identify the runtime ID from the newest .staging-<runtime-id>-* directory;
2. create the final content-addressed runtime directory:
   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>
3. copy the complete official packaged cua_node runtime from WindowsApps into that directory with:
   xcopy /E /I /H /Y /G
4. verify:
   • bin\node.exe
   • bin\node_repl.exe
   • manifest.json
5. relaunch ChatGPT.

In the successful repair on 26.825.6671.0, 4,679 files were copied. Immediately afterward:

• ChatGPT.exe --type=renderer appeared;
• codex.exe ... app-server appeared;
• the desktop window opened and could be closed/reopened normally.

After a Microsoft Store auto-update to 26.831.1445.0, the startup failure returned, indicating the workaround is runtime/version-specific and must be repeated when the content-addressed runtime ID changes.

Why this appears to be a product bug rather than broken local EFS

The system drive is NTFS 3.1, and a local EFS encryption test succeeds:

cipher /e <temp>\efs-test\test.txt → [OK]

The failure is specifically associated with relocation/extraction of packaged Application Protected resources from the MSIX/WindowsApps location into the user-writable runtime cache.

Expected behavior

The desktop app should:

1. reliably relocate/extract bundled Application Protected runtime resources into the user cache;
2. use a Windows copy path that supports a decrypted destination (equivalent to COPY_FILE_ALLOW_DECRYPTED_DESTINATION / xcopy /G) or use a safe buffered read/write fallback;
3. atomically finalize the content-addressed runtime;
4. recover from an incomplete .staging-* directory rather than creating a new failed staging directory on every launch;
5. surface the underlying relocation error instead of silently remaining headless.

Related public reports

• openai/codex #41540 — headless startup caused by Application Protected node_repl.exe relocation failure (0x80071770)
• openai/codex #41654 — repeated regressions across updates due to Application Protected runtime relocation failures
• openai/codex #40843 — MSIX bundled executable relocation fails with ERROR_ENCRYPTION_FAILED
• openai/codex #40791 — Windows startup blocker involving Application Protected codex.exe

Additional note

No WindowsApps ownership/ACLs, package files, registry EFS settings, or system encryption settings were modified to achieve the workaround.

What is the expected behavior?

Bug report: ChatGPT/Codex Desktop repeatedly fails to start on Windows after auto-update due to cua_node runtime relocation

Summary

ChatGPT/Codex Desktop on Windows repeatedly starts headless after Microsoft Store auto-updates. The main ChatGPT.exe, crashpad, GPU and utility processes are created, but ChatGPT.exe --type=renderer and codex.exe ... app-server are missing, and no usable window appears.

The problem reproduced on:

• OpenAI.Codex 26.825.6671.0
• after auto-update, again on OpenAI.Codex 26.831.1445.0

A normal reinstall/reset did not provide a durable fix.

Environment

• OS: Windows x64
• Distribution: Microsoft Store / MSIX
• Current package:
  • OpenAI.Codex 26.831.1445.0
  • package family: OpenAI.Codex_2p2nqsd0c76g0
• App ID:
  • OpenAI.Codex_2p2nqsd0c76g0!App
• System drive:
  • NTFS 3.1
• EFS test in the user's temp directory:
  • cipher /e <temp>\efs-test\test.txt
  • result: [OK]
  • so ordinary NTFS/EFS functionality on the system drive is working.

Symptoms

On launch, Windows AppModel reports successful package activation and process creation.

Observed process state during failure:

• main ChatGPT.exe: present
• crashpad handlers: present
• GPU process: present
• network utility process: present
• storage utility process: present
• ChatGPT.exe --type=renderer: missing
• codex.exe ... app-server: missing
• visible application window: missing / unusable

Disabling the updater did not resolve the issue.

Calling ShowWindow() on discovered Chromium windows also did not restore the UI while the renderer was absent.

Runtime staging failure

Under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

every failed launch created another directory of the form:

.staging-<runtime-id>-<random>

For the earlier affected build, multiple staging directories contained:

• bin\node.exe: present
• bin\node_repl.exe: missing

while the packaged source file existed under:

C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0\app\resources\cua_node\bin\node_repl.exe

More than twenty failed staging directories accumulated across repeated launches.

Confirmed workaround

The reliable workaround was to:

1. identify the runtime ID from the newest .staging-<runtime-id>-* directory;
2. create the final content-addressed runtime directory:
   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>
3. copy the complete official packaged cua_node runtime from WindowsApps into that directory with:
   xcopy /E /I /H /Y /G
4. verify:
   • bin\node.exe
   • bin\node_repl.exe
   • manifest.json
5. relaunch ChatGPT.

In the successful repair on 26.825.6671.0, 4,679 files were copied. Immediately afterward:

• ChatGPT.exe --type=renderer appeared;
• codex.exe ... app-server appeared;
• the desktop window opened and could be closed/reopened normally.

After a Microsoft Store auto-update to 26.831.1445.0, the startup failure returned, indicating the workaround is runtime/version-specific and must be repeated when the content-addressed runtime ID changes.

Why this appears to be a product bug rather than broken local EFS

The system drive is NTFS 3.1, and a local EFS encryption test succeeds:

cipher /e <temp>\efs-test\test.txt → [OK]

The failure is specifically associated with relocation/extraction of packaged Application Protected resources from the MSIX/WindowsApps location into the user-writable runtime cache.

Expected behavior

The desktop app should:

1. reliably relocate/extract bundled Application Protected runtime resources into the user cache;
2. use a Windows copy path that supports a decrypted destination (equivalent to COPY_FILE_ALLOW_DECRYPTED_DESTINATION / xcopy /G) or use a safe buffered read/write fallback;
3. atomically finalize the content-addressed runtime;
4. recover from an incomplete .staging-* directory rather than creating a new failed staging directory on every launch;
5. surface the underlying relocation error instead of silently remaining headless.

Related public reports

• openai/codex #41540 — headless startup caused by Application Protected node_repl.exe relocation failure (0x80071770)
• openai/codex #41654 — repeated regressions across updates due to Application Protected runtime relocation failures
• openai/codex #40843 — MSIX bundled executable relocation fails with ERROR_ENCRYPTION_FAILED
• openai/codex #40791 — Windows startup blocker involving Application Protected codex.exe

Additional note

No WindowsApps ownership/ACLs, package files, registry EFS settings, or system encryption settings were modified to achieve the workaround.

Additional information

No response

Start on Windows x64 with the MSIX package and reproduce the launch while inspecting %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node and its .staging-* directories. Compare the packaged resources, especially bin\node.exe, bin\node_repl.exe, and manifest.json, with the staged runtime and the reported relocation failure. Done means auto-updated installs complete staging, launch ChatGPT.exe --type=renderer and codex.exe ... app-server, and recover without repeated incomplete staging directories.