Activity

1. coolkkz

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 3, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   on Sep 3, 2026
3. github-actions commented on Sep 3, 2026

   

   github-actionsBot

   on Sep 3, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows Codex Desktop repeatedly regresses across updates due to Application Protected runtime relocation failures #41654
   • [Windows][26.825.6671.0] Headless startup persists after clean runtime reset; cua_node staging never finalizes #41850
   • [Windows][26.825.5331.0] Headless startup caused by Application Protected node_repl.exe relocation failure (0x80071770) #41540
   • Same issue confirmed on Windows 11 — with root-cause evidence. #42223

   Powered by Codex Action
4. Hoshanani commented on Sep 5, 2026

   

   Hoshanani

   on Sep 5, 2026

   More actions

   I can reproduce the same issue on newer Codex builds:

   • 26.901.5003.0
   • 26.901.5280.0

   Windows 11 Home 25H2, OS Build 26200.9278, x64.

   After each update, Codex starts multiple ChatGPT.exe processes in the background but no window appears.

   For 26.901.5280.0, the new runtime hash was:
   440c4f095d41ea30

   Failed launches created:
   .staging-440c4f095d41ea30-K01Wy1
   .staging-440c4f095d41ea30-aIMlCB

   Manually copying the bundled cua_node runtime from:

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

   to:

   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\440c4f095d41ea30

   using:

   xcopy /E /I /H /Y /G

   copied 4683 files.

   Afterward:
   node.exe = True
   node_repl.exe = True
   manifest.json = True

   Codex then launched normally.

   The issue reproduced again immediately after updating, so the runtime staging/relocation regression is still present in 26.901.5280.0.
5. StatXzy7 commented on Sep 10, 2026

   

   StatXzy7

   on Sep 10, 2026

   More actions

   I can confirm that the same cua_node runtime relocation failure is still reproducible on a newer Windows build:

   • Codex / ChatGPT package: OpenAI.Codex 26.903.9818.0
   • Platform: Windows 11 x64
   • Distribution: Microsoft Store / MSIX
   • Package family: OpenAI.Codex_2p2nqsd0c76g0
   • Affected runtime ID: e7fe122ad3cbcd58

   Observed startup behavior

   Windows AppX activation itself succeeded.

   AppModel-Runtime reported successful process creation and TWinUI reported successful activation. There were no relevant Code Integrity rejection events.

   During the failed launch, the following processes were present:

   • main ChatGPT.exe
   • crashpad
   • GPU process
   • network service
   • storage service

   However:

   • ChatGPT.exe --type=renderer was missing
   • no new codex.exe ... app-server process was spawned for the current ChatGPT process
   • MainWindowHandle remained 0
   • no GUI appeared

   Verbose startup logging also reached:

   [AppServerConnection] Initializing app-server transport
   [AppServerConnection] Starting app-server connection hostId=local transport=stdio
   [AppServerConnection] ... next=connecting
   

   but did not proceed to a successful app-server/renderer startup.

   Repeated CUA runtime staging failure

   Under:

   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node
   

   every failed launch created a new staging directory for the same runtime ID, for example:

   .staging-e7fe122ad3cbcd58-OehkqY
   .staging-e7fe122ad3cbcd58-mLpcfv
   .staging-e7fe122ad3cbcd58-rO2b1B
   .staging-e7fe122ad3cbcd58-dXt2b6
   .staging-e7fe122ad3cbcd58-jD9Ah3
   ...
   

   All newly created staging directories had the same incomplete state:

   bin\node.exe      = present
   bin\node_repl.exe = missing
   manifest.json     = missing
   

   An older finalized runtime (b58ca2eaa616c2da) was intact, including node.exe, node_repl.exe, and manifest.json.

   This strongly suggests that the newly required content-addressed runtime could not be fully materialized/finalized after the application update.

   Workaround confirmed on 26.903.9818.0

   I stopped the ChatGPT processes, identified the required runtime ID from the failed staging directories, and copied the complete bundled runtime from:

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

   to:

   %LOCALAPPDATA%\OpenAI\Codex\
   runtimes\cua_node\e7fe122ad3cbcd58
   

   using:

   xcopy "$src\*" "$dst\" /E /I /H /Y /G

   After the copy completed, the finalized runtime contained:

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

   I then relaunched ChatGPT/Codex Desktop and the GUI started successfully.

   No WindowsApps ownership, ACLs, package files, Defender settings, registry encryption settings, or system security settings were modified.

   Conclusion

   This provides another reproduction showing that the Windows/MSIX cua_node relocation/staging issue persists in 26.903.9818.0.

   The successful /G workaround continues to suggest that the Windows relocation path should support an Application Protected/encrypted source with a decrypted destination, or fall back to a buffered copy implementation.

   It may also be worth changing the runtime materialization flow so that it:

   1. validates/reuses a complete finalized runtime before staging;
   2. reports the underlying relocation/copy failure explicitly;
   3. does not create a new abandoned .staging-* directory on every launch;
   4. validates required files before atomically finalizing the runtime;
   5. uses Windows copy semantics equivalent to COPY_FILE_ALLOW_DECRYPTED_DESTINATION where applicable.

   I can provide additional logs or filesystem comparisons if useful.
6. Faye-663 commented on Sep 10, 2026

   

   Faye-663

   on Sep 10, 2026 – with ChatGPT Codex Connector

   More actions

   I can independently reproduce the same cua_node runtime staging failure on another Windows desktop build.

   Environment

   • Package: OpenAI.Codex 26.903.8094.0
   • Platform: Windows 11 x64 (10.0.26200)
   • Distribution: Microsoft Store / MSIX

   Microsoft Store / winget did not offer a newer package at the time of testing.

   Observed behavior

   After launching the updated unified ChatGPT/Codex desktop app:

   • ChatGPT.exe processes appeared in the background;
   • no visible application window was created;
   • the startup log stopped after:

   [sparkle] in_app_updates_policy_wait_started timeoutMs=300000
   Launching app ... enableSparkle=false enableUpdater=true ... packaged=true platform=win32
   Appshot hotkey inactive configured=true enabled=false platform=win32
   

   No later renderer, app-server, or window ready-to-show entries appeared.

   Repeated runtime staging failure

   Under:

   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node
   

   approximately 19 abandoned directories accumulated for the same runtime ID:

   .staging-b58ca2eaa616c2da-*
   

   The newest staging directory was incomplete:

   bin\node.exe      = present
   bin\node_repl.exe = missing
   manifest.json     = missing
   

   No finalized b58ca2eaa616c2da runtime directory was present.

   Repeated launches created additional staging directories with the same incomplete contents, strongly indicating that runtime materialization never reached finalization.

   Workaround status

   The xcopy /E /I /H /Y /G workaround described in this issue has not yet been executed or confirmed on this machine, so I am reporting this as an independent reproduction rather than a confirmed repair.

   No WindowsApps permissions, package files, registry settings, or .codex user data were modified during diagnosis.
7. saichaodeng-cmd commented on Sep 10, 2026

   

   saichaodeng-cmd

   on Sep 10, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce this repeatedly across recent Windows Codex Desktop updates, and the important part is that the workaround does not survive an app update when the required cua_node runtime hash changes.

   Observed sequence:

   • Codex Desktop 26.903.8094.0 failed to show any GUI even though background ChatGPT.exe processes started.
   • During the failed state, the process tree had the main process, crashpad, GPU, network, and storage services, but no ChatGPT.exe --type=renderer process.
   • %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node accumulated many .staging-* directories.
   • For the then-current runtime ID b58ca2eaa616c2da, the newest staging directory contained bin\node.exe but was missing bin\node_repl.exe.
   • Manually copying the bundled runtime from app\resources\cua_node into the finalized runtime directory with xcopy /E /I /H /Y /G fixed the launch, and renderer processes appeared normally afterward.

   After Codex Desktop auto-updated to 26.903.9818.0, the same problem returned with a new runtime ID:

   e7fe122ad3cbcd58

   The newest staging directory again showed:

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

   while the bundled runtime inside the installed MSIX contained all three files. The finalized runtime directory for e7fe122ad3cbcd58 did not exist yet. This shows that the relocation/materialization step is failing again after the update rather than the old cached runtime being corrupted.

   The CLI itself is healthy (codex-cli 0.154.0) and CODEX_CLI_PATH resolves correctly, so this appears independent of the CLI install.

   The main usability problem is that each Desktop update can introduce a new runtime hash and force the user to repeat the manual xcopy /G workaround. Please make the Windows runtime relocation path handle Application Protected/encrypted source files correctly (or otherwise materialize the runtime without failing), validate/reuse completed runtimes, and avoid leaving a new abandoned .staging-* directory on every failed launch.

   A permanent product fix would be much better than requiring users to manually inspect staging directories and copy several thousand runtime files after updates.
8. wanghoween-design commented on Sep 11, 2026

   

   wanghoween-design

   on Sep 11, 2026

   More actions

   I can reproduce this repeatedly across recent Windows Codex Desktop updates, and the important part is that the workaround does not survive an app update when the required cua_node runtime hash changes.

   Observed sequence:

   • Codex Desktop 26.903.8094.0 failed to show any GUI even though background ChatGPT.exe processes started.
   • During the failed state, the process tree had the main process, crashpad, GPU, network, and storage services, but no ChatGPT.exe --type=renderer process.
   • %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node accumulated many .staging-* directories.
   • For the then-current runtime ID b58ca2eaa616c2da, the newest staging directory contained bin\node.exe but was missing bin\node_repl.exe.
   • Manually copying the bundled runtime from app\resources\cua_node into the finalized runtime directory with xcopy /E /I /H /Y /G fixed the launch, and renderer processes appeared normally afterward.

   After Codex Desktop auto-updated to 26.903.9818.0, the same problem returned with a new runtime ID:

   e7fe122ad3cbcd58

   The newest staging directory again showed:

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

   while the bundled runtime inside the installed MSIX contained all three files. The finalized runtime directory for e7fe122ad3cbcd58 did not exist yet. This shows that the relocation/materialization step is failing again after the update rather than the old cached runtime being corrupted.

   The CLI itself is healthy (codex-cli 0.154.0) and CODEX_CLI_PATH resolves correctly, so this appears independent of the CLI install.

   The main usability problem is that each Desktop update can introduce a new runtime hash and force the user to repeat the manual xcopy /G workaround. Please make the Windows runtime relocation path handle Application Protected/encrypted source files correctly (or otherwise materialize the runtime without failing), validate/reuse completed runtimes, and avoid leaving a new abandoned .staging-* directory on every failed launch.

   A permanent product fix would be much better than requiring users to manually inspect staging directories and copy several thousand runtime files after updates.

   I can confirm the same behavior on my machine.

   My affected build was:

   • Codex Desktop: 26.903.8094.0
   • Runtime ID: b58ca2eaa616c2da

   After the update, Codex started background ChatGPT.exe processes but did not create a usable GUI. The cua_node directory repeatedly accumulated:

   .staging-b58ca2eaa616c2da-*
   

   while the finalized b58ca2eaa616c2da runtime directory was missing.

   Using the same workaround — manually copying the bundled app\resources\cua_node runtime into the finalized runtime directory with:

   xcopy /E /I /H /Y /G

   and then removing the failed .staging-* directories — immediately restored normal startup.

   I have also seen this recur after Codex updates when the required runtime hash changes, so this does not appear to be a one-time cache corruption.

   So +1 that this is still reproducible across recent Windows Desktop builds and appears tied to runtime materialization after updates.
9. Hoshanani commented on Sep 11, 2026

   

   Hoshanani

   on Sep 11, 2026

   More actions

   Update — September 11, 2026

   I tested this again today on:

   Codex / ChatGPT Desktop: OpenAI.Codex 26.903.9818.0
   Platform: Windows 11 x64
   Distribution: Microsoft Store / MSIX
   Install location:
   C:\Program Files\WindowsApps\OpenAI.Codex_26.903.9818.0_x64__2p2nqsd0c76g0
   Required cua_node runtime ID: e7fe122ad3cbcd58

   The issue did reproduce again initially on this build.

   During the failed launch state, %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node contained three incomplete staging directories for the same runtime ID:

   .staging-e7fe122ad3cbcd58-rhUrgc
   .staging-e7fe122ad3cbcd58-Y4GGcD
   .staging-e7fe122ad3cbcd58-Vi22eX

   They were created within only a few minutes of each other during repeated launch attempts.

   The newest staging directory contained:

   bin\node.exe = present
   bin\node_repl.exe = missing
   manifest.json = missing

   At that time, several ChatGPT.exe processes were running in the background, but every process reported:

   MainWindowHandle = 0
   MainWindowTitle = empty
   Responding = True

   No usable application window appeared.

   I also verified that the original bundled runtime inside the installed MSIX was complete:

   app\resources\cua_node\bin\node.exe = present
   app\resources\cua_node\bin\node_repl.exe = present
   app\resources\cua_node\manifest.json = present

   This confirms that the missing files were present in the package source while the per-user runtime staging copy was incomplete.

   Importantly, I did not apply the manual xcopy /G workaround during this test.

   After several launch attempts, the runtime eventually finalized successfully on its own.

   The final runtime directory became:

   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\e7fe122ad3cbcd58

   and it contained:

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

   At that point:

   Final runtime exists = True
   Staging count = 0

   The normal startup process tree also appeared:

   ChatGPT.exe --type=renderer was present
   codex.exe ... app-server was present
   the app-server was using:
   CODEX_MCP_NODE_PATH=
   C:\Users\hanan\AppData\Local\OpenAI\Codex\runtimes\cua_node\e7fe122ad3cbcd58\bin\node.exe

   I then completely terminated all ChatGPT.exe and codex.exe processes and tested launching again.

   One launch took noticeably longer and did not show the window after roughly 20 seconds; after another launch attempt, the GUI appeared. Subsequent full close/relaunch tests have also succeeded.

   So the current status on my machine is:

   Codex is working now on 26.903.9818.0, but I would not consider the underlying issue fully resolved.

   The important observation is that the runtime materialization still failed multiple times on the current build, created incomplete .staging-* directories, and only later finalized successfully without manual intervention.

   This makes the behavior appear intermittent / retry-dependent, rather than a permanently fixed runtime relocation path.

   I will continue testing future Codex Desktop updates, especially when the required cua_node runtime hash changes, to see whether the same staging failure returns.

   👍React with 👍1Reacted by Howie
10. arphox commented on Sep 22, 2026

    

    arphox

    on Sep 22, 2026

    More actions

    I also experience this issue, and this with MANY other issues are basically messing up my ChatGPT Codex local Windows workflow. Please start fixing these bugs.
11. yousizaitianqiong commented on Oct 10, 2026

    

    yousizaitianqiong

    on Oct 10, 2026

    More actions

    Additional Windows runtime diagnostics collected on 2026-10-10.

    My earlier post-update symptoms match this report: background ChatGPT.exe
    processes, no usable window, and incomplete cua_node staging directories.
    Pre-installing the complete official runtime with xcopy /G restored startup.

    Current verified environment:

    • Windows 11 Home x64, OS version 10.0.26200.
    • Microsoft Store/MSIX package: OpenAI.Codex 26.1007.2314.0.
      This is the Get-AppxPackage version, not the About-dialog version.
    • Package status: Ok.
    • Runtime ID: cfb32733c877621e.
    • Packaged bin/node_repl.exe exists and cipher /c reports Application Protected.
    • After preparation, all 2,365 runtime files match the packaged source by
      size and SHA-256; approximately 251 MB.

    I use an external launcher that prepares the runtime before activating the app.
    Its recorded preparation times were:

    Package version	Time before activation
    26.928.2636.0	158.8 s
    26.930.2377.0	132.1 s
    26.930.3930.0	121.2 s
    26.1002.7124.0	153.0 s
    26.1007.2314.0	176.4 s

    The latest run spent 149.3 seconds between copy_started and copy_verified.
    A subsequent read-only assessment of the complete runtime took about 1.74 s.

    These timings measure the external workaround, not native application startup.
    I have not independently reproduced an unmodified cold-start relocation failure
    on 26.1007.2314.0. The currently installed startup code already contains a
    buffered read/write fallback.

    Could maintainers confirm which release resolves this failure mode and whether
    the workaround can now be removed? Please also consider visible preparation
    progress, bounded recovery, and safe cleanup of failed staging directories.

    No WindowsApps ownership/ACL changes or security weakening were used for this
    runtime preparation. Personal paths, account information, and raw logs are omitted.
12. yousizaitianqiong commented on Oct 10, 2026

    

    yousizaitianqiong

    on Oct 10, 2026

    More actions

    Follow-up: I have published my per-user Windows runtime launcher so
    other affected users can inspect, reproduce, and improve this workaround:

    • Source (MIT):
      https://github.com/yousizaitianqiong/codex-windows-runtime-launcher
    • English documentation:
      https://github.com/yousizaitianqiong/codex-windows-runtime-launcher/blob/v1.1.1/README.en.md
    • v1.1.1 download:
      https://github.com/yousizaitianqiong/codex-windows-runtime-launcher/releases/tag/v1.1.1

    It checks and prepares the runtime before activating Codex, uses up to
    four file-stream workers, independently verifies all destination files,
    and retains a single xcopy /G fallback for source permission/encryption
    read compatibility errors.

    On MSIX package 26.1007.2314.0, a single sequential comparison measured
    copy plus full verification at 146.434 seconds for the earlier pipeline
    and 13.791 seconds for the stream pipeline. All 2,365 files matched by
    size and SHA-256. System caches were not cleared.

    These are external workaround timings, not native application startup
    timings. The tested app already contains a buffered read/write fallback;
    I have not independently reproduced an unmodified cold-start failure
    on this package version.

    No WindowsApps ownership/ACL or Defender changes are required.
    The repository does not distribute official runtime binaries or icons.

    Feedback, reproducible reports, and pull requests are welcome.