Skip to content

[Windows][26.825.5331.0] After Store auto-update, app starts headless for ~12 min — update-policy gate + cua_node runtime re-extraction block window creation; main process event loop synchronously blocked #41539

Open
Open
[Windows][26.825.5331.0] After Store auto-update, app starts headless for ~12 min — update-policy gate + cua_node runtime re-extraction block window creation; main process event loop synchronously blocked#41539
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcomputer-useperformancewindows-osIssues related to Codex on Windows systems

Description

@tedburner
tedburner
opened on Aug 29, 2026

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

26.825.5331.0 (MSIX OpenAI.Codex, auto-updated from 26.820.10647.0 on 2026-08-29)

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Symptom

After the Microsoft Store auto-updated the app from 26.820.10647.0 to 26.825.5331.0, launching it shows only background ChatGPT.exe processes — no window, no error. Windows Event Viewer logs Application Hang 1002. Killing and relaunching reproduced it 4/4 times.

Startup log freezes at exactly 3 lines

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

At that point the process tree has only crashpad-handler / gpu-process / network / storage utilities — no renderer is spawned, all processes report Responding=True with MainWindowHandle=0. No Crashpad dumps.

What unblocks it

Nothing the user does — after 11m47s the main process resumed on its own, and the window appeared within seconds (recovered at 21:50:48 local for a 21:39:01 launch). Earlier attempts were all killed before the stall finished, which made it look like a permanent failure.

Key evidence: the event loop is synchronously blocked

From a 26.820 session on 2026-08-28 with the same freeze signature:

03:27:21.530 [AppServerConnection] app_server_connection.state_changed ... next=connecting
        <-- 8 minute gap, zero log output -->
03:35:33.087 warning Failed to load shell env caller=startup detail="Timed out after 5000ms." durationMs=491923 timeoutMs=5000
03:35:33.088 info [sparkle] in_app_updates_policy_timeout policy=pending timeoutMs=300000
03:35:33.250 info [IpcRouter] I am the router
03:35:38.443 info [window-manager] window main frame finished load
03:35:38.797 info [window-manager] window ready-to-show

Two details matter:

  1. A step configured to time out after 5000 ms actually took 491,923 ms.
  2. The 5000 ms shell-env timeout and the 300000 ms update-policy timeout fired at the same instant when the stall ended.

Pending timers cannot fire while the main process event loop is blocked — so the startup critical path (shell-env load and/or update-policy wait) is executing synchronously, and its own timeouts are ineffective during the stall.

Runtime re-extraction evidence (likely the trigger)

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ accumulated 12 stale .staging-* directories: 10 from 2026-08-28 (old runtime hash f24ab376120677c2) and one created at the exact time of tonight's first failed launch (e4d75eceaa042f20 — the 26.825 runtime hash). The app unblocked right after this extraction finished. This matches the mechanisms reported in #41170 and #41056.

Environment notes (ruled out)

  • Proxy chain healthy during all failures: SOCKS5 tunnel (127.0.0.1:7897) responds in <1s; chatgpt.com / auth.openai.com reachable; mihomo service logs clean.
  • Package status Ok; no PS profile / cmd AutoRun hooks; GPU/VM irrelevant (hang is pre-window).
  • This machine also runs a WFP/WinDivert per-process interceptor (ChatGPT.exe → forced local proxy, no localhost exemption). It does not cause this stall (it was disabled mid-test with no change), but may aggravate child-process spawn latency.

Expected behavior

  1. The update-policy wait and shell-env load must not sit on the startup critical path, and must be enforced asynchronously so a slow/hung step can never freeze the whole main process.
  2. Runtime re-extraction after an update should show a visible progress state instead of a silent headless window.
  3. Failed .staging-* directories should be resumed/cleaned, not re-created from scratch on every launch (12 leftovers ≈ wasted disk).

Related issues (searched before filing)

Filing separately because this report adds the synchronous-blocking proof (simultaneous timer firing) and staging-directory evidence. Happy to consolidate into #41339 if maintainers prefer.

What steps can reproduce the bug?

  1. Microsoft Store auto-updates the OpenAI.Codex MSIX package from 26.820.10647.0 to 26.825.5331.0.
  2. Launch the app from the Start menu.
  3. Result: multiple ChatGPT.exe background processes appear (all Responding=True, MainWindowHandle=0), but no window ever shows. Windows Event Viewer logs Application Hang 1002.
  4. The desktop log freezes permanently at 3 lines (last line: Appshot hotkey inactive configured=true enabled=false platform=win32); no renderer process is spawned; no Crashpad dumps.
  5. Killing all ChatGPT.exe processes and relaunching reproduces the hang deterministically (4/4 attempts on 2026-08-29).
  6. The hang self-recovers after ~12 minutes: on one launch (started 21:39:01 local) the main process unblocked at 21:50:48 and the window appeared within seconds. Attempts killed before that point looked permanently broken.

Note: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ accumulates stale .staging-* directories on each failed launch (12 leftovers here; the newest one, e4d75eceaa042f20, was created at the moment of the first failed launch after the update — it is the 26.825 runtime hash).

What is the expected behavior?

No response

Additional information

No response

Activity

  1. tedburner
    added
    appIssues related to the Codex desktop app
    on Aug 29, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    performance
    computer-use
    on Aug 29, 2026

  3. github-actions commented on Aug 29, 2026

    @github-actions
    github-actionsbot
    on Aug 29, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. zemeng5208 commented on Aug 29, 2026

    @zemeng5208
    zemeng5208
    on Aug 29, 2026 – with ChatGPT Codex Connector

    I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

    This report looks relevant to one narrow local layer WinBridge can help diagnose/recover: the per-user cua_node relocation/materialization state under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node, especially repeated or abandoned .staging-* directories, incomplete runtime contents, and version/hash drift after an app update.

    In this issue, the 12 leftover staging directories plus a new staging tree being created at the failing launch are useful signals. WinBridge can help distinguish a genuinely incomplete/stale local CUA runtime from a healthy runtime that is merely being re-extracted slowly, and can repair the local materialized state when the problem is caused by partial staging or stale runtime metadata.

    Important limitation: the strongest evidence here points to an upstream startup-path problem too — the main-process event loop is synchronously blocked long enough that the nominal 5 s / 300 s timers only fire after the block ends. If the current runtime eventually materializes correctly and the remaining delay is caused by Codex doing extraction/update-policy/shell-env work synchronously on the startup critical path, WinBridge cannot fix that architectural/performance bug. It also does not modify WindowsApps or bypass package protection.

    So I would treat WinBridge as a way to verify/repair the local cua_node staging layer here, not as a guaranteed fix for the ~12 minute headless startup itself.

  5. Lin-chpin commented on Aug 30, 2026

    @Lin-chpin
    Lin-chpin
    on Aug 30, 2026 – with ChatGPT Codex Connector

    Additional reproduction details from a Windows Store installation of Codex.

    Environment:

    • Windows 11 Home Chinese, build 10.0.26200, x64
    • OpenAI.Codex Store package 26.825.5331.0
    • Package status reported as OK

    Observed behavior after the Store auto-update:

    • Launching the app produced multiple ChatGPT.exe processes but no visible window.
    • The processes had MainWindowHandle=0 and an empty MainWindowTitle; they remained responsive.
    • There was no useful Event Viewer error explaining the startup failure.
    • AppX re-registration, app reset, a fresh UI profile, and disabling GPU acceleration did not immediately resolve it.

    Runtime evidence:

    • %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ contained about 40 stale .staging-* directories.
    • After stopping ChatGPT and removing the stale staging directories, the next launch created a new staging directory and spent several minutes extracting the bundled cua_node runtime.

    Workaround that restored the window:

    1. Stop all ChatGPT.exe processes.
    2. Remove stale .staging-* directories under the cua_node runtime directory.
    3. Set CODEX_SPARKLE_ENABLED=false for the launch.
    4. Launch the packaged app through Invoke-CommandInDesktopPackage.
    5. After the runtime extraction completed (roughly 8 minutes in this case), the normal ChatGPT window appeared.

    This looks consistent with the startup path synchronously blocking while the bundled cua_node runtime is being staged/extracted after an update. The app should avoid appearing headless for many minutes and should expose progress or fail gracefully if runtime staging is slow or interrupted.

  6. jubudouyun-lab commented on Sep 2, 2026

    @jubudouyun-lab
    jubudouyun-lab
    on Sep 2, 2026

    I can reproduce the same prolonged headless startup on newer builds, with timestamped process snapshots from three affected versions. This appears to be the same failure mode as this issue and #41096, rather than a renderer crash or an authentication/network failure.

    Environment

    • Windows 11 25H2, x64, build 26200
    • Microsoft Store / MSIX package: OpenAI.Codex
    • Current affected package: 26.831.2377.0
    • Bundled Codex CLI: 0.152.1
    • AppX status: Ok

    Latest reproduction (26.831.2377.0, 2026-09-02)

    Two consecutive launches reproduced the same state.

    Attempt 1:

    • Main ChatGPT.exe started at 20:40:32.
    • At +59 seconds, MainWindowHandle=0.
    • No --type=renderer process.
    • No codex.exe app-server process.
    • Main process had consumed about 78 CPU seconds in 59 seconds and had about 1.1 GB private memory.

    Attempt 2:

    • A new main ChatGPT.exe started at 20:43:55.
    • At +31 seconds, MainWindowHandle=0, with no renderer or app-server.
    • The only six processes were the main process, two Crashpad handlers, GPU process, Network Service, and Storage Service.
    • The renderer processes and Codex app-server finally appeared at 20:54:21, about 10 minutes 26 seconds after the main process started.
    • At about +877 seconds, the main process had accumulated about 832 CPU seconds, so the high-CPU loop continued through most of the headless period.
    • The window eventually became visible without reinstalling or resetting the app.

    Cross-version history on the same machine

    • 26.825.5331.0: main process to first renderer approximately 8m42s.
    • 26.825.6671.0: main process to first renderer approximately 7m50s, with sustained high CPU.
    • 26.831.2377.0: main process to first renderer approximately 10m26s, with sustained high CPU.

    The behavior therefore persists across at least these three package versions.

    Negative findings

    • No HTTP 401, 403, 5xx, token_expired, or timeout during the affected launch.
    • GPU, Network Service, and Storage Service start successfully before the stall.
    • No Crashpad .dmp is generated.
    • No renderer process exists during the headless period, so this is not a renderer-started-then-crashed case.
    • No AppX deployment was running during the affected launch. The current package had registered successfully about eight hours earlier.
    • No persistent CODEX_SPARKLE_ENABLED, NODE_OPTIONS, Electron launch-argument, proxy, or CA override environment variables were present.
    • Codex CLI starts normally when the desktop app finally reaches the app-server stage.

    This looks like the Electron main process becoming CPU-bound before renderer/window creation, then eventually unblocking after roughly 8–10 minutes. Please let me know if a sanitized ETW trace or another bounded diagnostic would be useful. I have retained timestamped process inventories and relevant Windows/AppX event exports, but have intentionally not posted raw logs containing local paths or task names.

  7. chrforever commented on Sep 3, 2026

    @chrforever
    chrforever
    on Sep 3, 2026

    Reproduced on newer 26.901.1978.0, Windows 11 10.0.26100 x64, after an in-app update. UDP was disabled before testing. Launch began 09:05:57; at 09:16:04 Desktop logged Failed to load shell env ... Timed out after 5000ms ... durationMs=606573, and [sparkle] in_app_updates_policy_timeout policy=pending timeoutMs=300000 at the same timestamp. The app-server was only spawned at 09:16:06 and CLI initialized at 09:16:06.966; an immediately preceding pre-update launch initialized in ~3s. Control checks: Windows PowerShell 5.1 -NoProfile 347ms, Codex-bundled PowerShell 7.6.4 -NoProfile 395ms, normal cmd exit succeeds, with no PowerShell profile or CMD AutoRun. After UI appears, WindowsApps-to-.codex/.tmp/bundled-marketplaces copies also fail and that directory stays empty; logged after startup, so it appears secondary. Full sanitized logs available on request.

  8. chrforever commented on Sep 4, 2026

    @chrforever
    chrforever
    on Sep 4, 2026

    New reproduction after another in-app update: Desktop 26.901.2854.0 on Windows 11 10.0.26100 x64. App process launched at 01:23:34.282Z, remote-connections/window-context refresh_started at 01:23:34.434Z, then no window for ~10m35s. At 01:34:04.745Z that refresh completed with zero saved/discovered connections; at the same moment shell-env reported timeoutMs=5000 but durationMs=630472, and the 300000ms in-app update-policy timeout fired. The app-server spawned at 01:34:08, first main window loaded at 01:34:09, and critical-path total was startupElapsedMs=635628. A normal comparison launch was ~3883ms. UDP remains disabled. codex doctor reports desktop update/runtime CDN persistent.oaistatic.com unreachable while ChatGPT WebSocket is healthy. This seems to strengthen that an update/CDN-related wait blocks the main process before window creation; plugin work happens after the window appears. Sanitized detailed logs available on request.

  9. neon3d commented on Sep 5, 2026

    @neon3d
    neon3d
    on Sep 5, 2026

    Reproduced on September 5, 2026 with Windows MSIX package OpenAI.Codex 26.901.5280.0 (desktop logs report release 26.901.41600). Please prioritize visible startup progress, even before the underlying performance problem is fully fixed.

    The user sees no window for several minutes and cannot tell whether the app is preparing components, has crashed, or needs to be launched again.

    Sanitized evidence from this launch

    All timestamps below are UTC on September 5, 2026:

    • 09:08:27.761: Launching app.
    • 09:08:27.898: app-server connection moves to connecting.
    • 09:08:28.932 through 09:16:58.213: creation timestamps of files in the new local cua_node runtime. The completed directory contains 4,684 files totaling approximately 322 MiB; its manifest was created at the end of this interval.
    • 09:17:00.866: Failed to load shell env, with timeoutMs=5000 but durationMs=513104. The update-policy timeout is logged at the same timestamp.
    • 09:17:04.350: app-server process spawned.
    • 09:17:04.765: startup critical path completed, startupElapsedMs=517280.
    • 09:17:05.029: main window ready-to-show.

    This places roughly 8.5 minutes of runtime preparation inside the interval before the main window appears. The timing strongly implicates component preparation, but we have not isolated why file creation is so slow or verified the implementation with a profiler. Other completed launches in the same machine's logs took approximately 3.6-5.8 seconds. This was a read-only investigation; no cache reset or controlled restart was performed.

    Requested UX improvement

    1. Show a lightweight startup window immediately, before preparing bundled runtimes.
    2. Display the current stage, for example: "Preparing components after an update. This may take several minutes."
    3. Show real progress (files or bytes processed) when a total is available. Otherwise show an indeterminate indicator, elapsed time, and a periodically updated status rather than a fabricated percentage.
    4. Keep the progress window responsive by moving long-running preparation off the UI/main event loop.
    5. On failure, show an actionable error with a retry option and access to diagnostic information.

    Even a reliable stage indicator would substantially reduce the impression that the app is broken and discourage users from repeatedly terminating and relaunching it during preparation. Raw logs and personal paths are intentionally omitted.

  10. lzxqwer commented on Sep 9, 2026

    @lzxqwer
    lzxqwer
    on Sep 9, 2026

    I can reproduce this on a current Windows Store build, and the desktop logs show the same 300-second startup gate.

    Environment

    • Codex Desktop (Microsoft Store): 26.903.8094.0, x64
    • Windows: Microsoft Windows NT 10.0.26100.0, x64
    • Package status: Ok

    User-visible behavior

    After a Windows boot, the first Codex launch creates several ChatGPT.exe processes in Task Manager but does not show a window for several minutes. Once the window finally appears, subsequent launches are fast. The behavior also returns after an app update.

    Log evidence

    On the slow launch after the update to 26.903.8094.0:

    2026-09-09T20:44:12.510Z [sparkle] in_app_updates_policy_wait_started timeoutMs=300000
2026-09-09T20:49:16.175Z windows_core_runtime_component_resolved component=node source=copied
2026-09-09T20:49:16.184Z windows_core_runtime_component_resolved component=node-repl source=copied
2026-09-09T20:49:16.785Z [sparkle] in_app_updates_policy_timeout policy=pending timeoutMs=300000
2026-09-09T20:49:20.407Z [window-manager] window ready-to-show
2026-09-09T20:49:21.383Z [startup] Host startup critical-path phases completed startupElapsedMs=312529

    The copied cua_node runtime directory was created at 20:44:14Z and its final files (node_repl.exe, npm scripts, and related files) were written around 20:49:11Z-20:49:12Z.

    A later launch reused the same runtime and completed normally:

    2026-09-09T22:22:53.293Z [sparkle] in_app_updates_policy_wait_started timeoutMs=300000
2026-09-09T22:22:54.656Z windows_core_runtime_component_resolved component=node source=copied
2026-09-09T22:22:55.652Z [window-manager] window ready-to-show startupElapsedMs=982
2026-09-09T22:22:55.717Z [startup] Host startup critical-path phases completed startupElapsedMs=2670

    There was also a slow launch on the preceding 26.901.6511.0 build where the runtime was already present:

    2026-09-09T12:50:01.976Z [sparkle] in_app_updates_policy_wait_started timeoutMs=300000
2026-09-09T12:54:38.580Z Failed to load shell env caller=startup detail="Timed out after 5000ms." durationMs=276597
2026-09-09T12:54:41.139Z [window-manager] window ready-to-show
2026-09-09T12:54:42.523Z [startup] Host startup critical-path phases completed startupElapsedMs=283155
2026-09-09T12:55:01.864Z [sparkle] in_app_updates_policy_timeout policy=pending timeoutMs=300000

    This suggests that runtime copying explains the post-update occurrence, while the repeat after a cold boot may involve the update-policy/bootstrap gate even when the runtime already exists.

    Expected behavior

    The main window should appear promptly. If first-run runtime preparation is required, the app should show a visible progress window and should not block window creation on a five-minute update-policy timeout.

  11. Jianyuanxi commented on Sep 10, 2026

    @Jianyuanxi
    Jianyuanxi
    on Sep 10, 2026

    Adding quantified data from the same failure mode on a Store/MSIX install. My delays are shorter than the reports above (4–6 min vs 8–10 min), but I was able to measure the copy step directly and run an AV control experiment.

    Environment: Windows 11 Pro for Workstations, build 26200, x64. Store/MSIX OpenAI.Codex_*_x64__2p2nqsd0c76g0, Status: Ok. No .staging-* directories present at any point — the runtime dirs were all finalized, so this reproduces without the stale-staging condition.

    The copy step, measured

    Launch                              05:31:05.305
runtimes\cua_node\<hash>\ created   05:35:12      259 MB / 4052 files
bin\<hash>\ (ripgrep) created       05:35:22      4.1 MB
Block ends, renderers spawn         05:35:21

    247 s for 4052 files ≈ 61 ms per file. The hash-named directory is content-addressed, so every update invalidates it and forces a full re-copy; subsequent launches hit the existing directory and start in ~5 s (measured: 335 s → 5 s on an immediate restart of the same build).

    It is not I/O bandwidth. Sequential read from the MSIX package measured 1.4 GB/s (app.asar, 100 MB), versus 1.6 GB/s from a normal path on the same disk. The per-file overhead dominates, which also explains why the main process shows ~95% kernel-mode CPU while ReadOperationCount stays low (memory-mapped reads are not counted there).

    AV control experiment

    Real-time protection is an aggravating factor, not the cause:

    Real-time AV Launch → window
    Kaspersky active 283 s / 269 s / 335 s
    Kaspersky paused, Defender not taking over 257 s

    Verified paused via productState 266240 → 270336, avp.exe CPU +0.00 s over 5 s, and Get-MpComputerStatus reporting AMRunningMode: Not running. Main-process kernel-mode CPU was 5703 ms / 6 s with AV off versus 5594 ms / 6 s with it on — essentially identical, so the kernel-time burn is inherent to the copy path rather than caused by scanning.

    Corroborating the event-loop observation in this thread

    Failed to load shell env caller=startup detail="Timed out after 5000ms." durationMs=255172

    The 5 s timer fired only after the block ended, and durationMs tracked the total block duration across every run (255 s / 331 s / 266 s), which makes it a convenient measurement handle for this bug.

    The first log line after the gap is consistently:

    windows_core_runtime_component_resolved component=node consumer=resolver ... source=copied

    Suggestion

    Parallelize or batch the runtime materialization, and move it off the window-creation critical path so the UI can appear with a progress indicator instead of staying headless. Since the directory is content-addressed, only files whose hashes actually changed between versions need re-copying — a full 4052-file re-copy on every update looks avoidable.

  12. aiken070707 commented on Sep 17, 2026

    @aiken070707
    aiken070707
    on Sep 17, 2026

    Reproducing this consistently on Windows 11 (build 26200.9445, 25H2) on a
    corporate-managed device, across seven app updates in thirteen days.

    Versions affected here: 26.831.2377.0, 26.901.4073.0, 26.901.6511.0,
    26.903.8094.0, 26.903.9818.0, 26.908.4834.0, 26.908.9136.0.

    11 measured launches — every one logged resultSource=load status=timed_out; the step has never once succeeded on this machine:

    launch durationMs (timeout is 5000)
    09-02 11:46 13,727
    09-02 11:50 8,161
    09-03 10:28 173,445
    09-04 10:00 5,715
    09-04 14:50 5,764
    09-07 11:20 179,798
    09-07 11:24 370,197
    09-09 11:56 380,936
    09-10 17:02 158,498
    09-15 09:11 314,927
    09-15 16:57 684,122

    Worst case was 730 s from launch to visible window. The window appears
    ~16 s after the step finally returns (ready-to-show startupElapsedMs).

    I can independently confirm your event-loop observation: during the stall
    the app writes nothing at all to its log, and then two unrelated timers
    fire within 1 ms of each other — the 5000 ms shell-env timeout and the
    300,000 ms update-policy timeout, the latter ~80 s past its own deadline.

    A second, separately managed machine reproduces it on the same version:
    durationMs=168453, total critical-path startup 191,836 ms. That log
    reports pathEntryCount=23 vs 15 on mine — different PATH, same failure,
    so PATH content is not the trigger.

    On your cua_node re-extraction hypothesis — partial support, with a
    caveat.     %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ here holds six
    runtime dirs, and their creation timestamps land exactly on slow launches: 09-03 10:28:51 -> 173,445 ms
    09-09 11:56:35 -> 380,936 ms
    09-15 16:57:44 -> 684,122 ms (worst)
    No runtime dir is created during a fast launch. But several slow
    launches created none at all (09-07 11:20 and 11:24, 09-10 17:02,
    09-15 09:11), and I have zero .staging-* directories, yet it still
    stalls. So re-extraction looks sufficient but not necessary, and the stale
    staging accumulation is not a precondition.

    Ruled out here, all reproducing the stall identically: reboot; Windows
    Repair; Windows Reset (profile 470 MB -> fresh 11 MB); full uninstall plus
    clean Store reinstall; clearing GPU/shader/CRX caches (--disable-gpu made
    it strictly worse, no window created at all); the app's 373 MB helper
    binaries being AV-cold (one update did not re-extract them and startup
    still took 7 minutes); Windows servicing (a slow launch occurred before that
    month's KB cluster installed, and both fast launches occurred after it);
    shell profile scripts (none exist on this machine); VPN (not connected, and
    the app opens zero outbound TCP connections during the stall).

    The practical impact is that the app looks hung rather than slow, so the
    natural response is to click the icon again or force-quit — both of which
    restart the work and make recovery much longer. Leaving it completely
    untouched is the only thing that works.

  13. Jianyuanxi commented on Sep 18, 2026

    @Jianyuanxi
    Jianyuanxi
    on Sep 18, 2026

    Update on my earlier report: the stall is gone on my machine. The cause was the one @mashirou1234 identified in #41170.

    My package was installed on a non-system volume, so its files were EFS-encrypted. Because of that, the app's copyFileSync failed on every runtime file and fell back to read+write. After I moved the package to C: via Settings → Apps → Codex → Move, three consecutive updates relaunched to a visible window in 13.9 s, 17.9 s and 14.4 s. Before the move it took 257–335 s. Details and numbers: #41170.

    @aiken070707, on a corporate-managed device it may be worth checking whether the package files are encrypted. That could come from install location or from policy. Run:

    $p = (Get-AppxPackage OpenAI.Codex).InstallLocation
(Get-Item $p).LinkType
(Get-ChildItem "$p\app" -Recurse -File | Select -First 200 | ? { $_.Attributes -band 'Encrypted' }).Count

    A non-zero count would point to the same mechanism. Separately, your slow launches that created no new cua_node directory may involve other runtime copies. In my case, bin\<hash>\ (ripgrep and the codex*.exe helpers, about 385 MB) is also re-materialized after updates.

  14. aiken070707 commented on Sep 21, 2026

    @aiken070707
    aiken070707
    on Sep 21, 2026

    Thanks @Jianyuanxi - checked, and EFS does not apply here, so there is at
    least one more mechanism producing this.

    $p = (Get-AppxPackage OpenAI.Codex).InstallLocation
    -> C:\Program Files\WindowsApps\OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0
    LinkType: (empty)
    Encrypted file count in \app (first 200): 0

    Package is on the system volume, attributes are plain Archive, and the
    copied runtime files are not encrypted either. So on this machine the
    per-file cost is not an EFS copyFileSync fallback.

    Still reproducing on 26.915.4065.0 today: durationMs=285441. Sequence:

    10:02 launch
    10:02:58 runtimes\cua_node<hash> created (251 MB / 4,123 files)
    ~10:07 shell-env returns, durationMs=285,441
    10:07:42 bin<hash> created (393.9 MB)
    10:07:43 bin<hash> created (4.2 MB, ripgrep)

    That confirms your second point: bin<hash>\ is re-materialized after
    updates as well, ~394 MB here. So each update triggers two separate
    copies, roughly 645 MB in total, not just the cua_node tree.

    My full history is now 5.7 s to 684.1 s across 12 launches on eight
    package versions since 02 September.

  15. Jianyuanxi commented on Sep 21, 2026

    @Jianyuanxi
    Jianyuanxi
    on Sep 21, 2026

    Thanks for checking — that rules EFS out on your machine, and the two cases together separate the two costs.

    On my machine, now that the package is unencrypted, the same 4,123-file / 251 MB cua_node tree copies in 2–5 s, and a 200-file benchmark with the bundled Node runs in 1,424–1,833 ms with 0 copyFileSync failures, i.e. 7–9 ms per file. Your 285 s over roughly 4,100 files works out to about 70 ms per file with EFS excluded, so something on that machine is adding an order of magnitude on top of the plain copy.

    Rather than guess, it is worth measuring the copy in isolation. The snippet below reproduces the app's own copy pattern (copyFileSync, falling back to read+write on failure) over 200 files from the installed package, using the runtime's own Node. It writes to a temp directory and deletes it afterwards, and touches nothing in the package or the runtime cache. I ran it verbatim on my machine before posting: 200 files 1833 ms copyFail 0.

    $p = (Get-AppxPackage OpenAI.Codex).InstallLocation
$node = (Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node" -Recurse -Filter node.exe | Select-Object -First 1).FullName
@'
const fs=require("fs"),path=require("path"),os=require("os");
const src=process.argv[2],files=[];
(function w(d){for(const e of fs.readdirSync(d,{withFileTypes:true})){if(files.length>=200)return;const p=path.join(d,e.name);e.isDirectory()?w(p):files.push(p);}})(src);
const dst=fs.mkdtempSync(path.join(os.tmpdir(),"cp-"));let fail=0;const t=Date.now();
files.forEach((f,i)=>{try{fs.copyFileSync(f,path.join(dst,""+i))}catch(e){fail++;fs.writeFileSync(path.join(dst,""+i),fs.readFileSync(f))}});
console.log(files.length,"files",Date.now()-t,"ms  copyFail",fail);
fs.rmSync(dst,{recursive:true,force:true});
'@ | Out-File -Encoding utf8 "$env:TEMP\cp.js"
& $node "$env:TEMP\cp.js" "$p\app\resources"

    Two possible outcomes:

    • Around 1–2 s, 0 failures. Per-file copy is normal on that machine, so the ~70 ms is not inherent to the copy call and the extra cost is coming from elsewhere in the startup path — worth timing the individual phases.
    • Tens of seconds. The copy itself is slow there. On a managed device the usual cause is a filter driver in the write path: on-access AV, EDR, or DLP inspecting every created file. The temp directory is a different path from the runtime cache, so if the benchmark is fast but real startup is slow, an exclusion or policy scoped to %LOCALAPPDATA%\OpenAI\Codex (or to WindowsApps) becomes the thing to check with whoever manages the device.

    Caveat on the benchmark: it copies from app\resources, not the cua_node source tree, and 200 files is a small sample. It measures per-file copy cost on that volume pair, not the app's full work.

    On AV, from my own measurements: it was not the root cause but it was a real aggravator. With the package still encrypted, launch to window was 283 / 269 / 335 s with Kaspersky real-time protection on and 257 s with it paused, and main-process kernel-mode CPU was essentially unchanged (5,594 ms vs 5,703 ms over 6 s), so the kernel time belonged to the copy path itself rather than to scanning. A corporate EDR typically costs far more per file than a consumer product does.

    Your 393.9 MB for bin\<hash>\ matches mine (385 MB of codex*.exe helpers plus 4 MB ripgrep). Stated plainly for the maintainers: every update re-materializes roughly 645 MB across two separate trees, synchronously, before any window is created.

  16. DearPureone commented on Sep 27, 2026

    @DearPureone
    DearPureone
    on Sep 27, 2026

    Additional reproduction on Windows for the Desktop startup-spinner issue.

    Environment:

    • Windows 11 Pro x64, build 26200
    • Microsoft Store package OpenAI.Codex 26.924.2738.0
    • Codex CLI 0.157.1
    • ChatGPT authentication

    Symptoms:

    • A cold launch shows the ChatGPT/Codex loading spinner indefinitely.
    • ChatGPT.exe and its internal codex.exe app-server remain responsive, but the UI never becomes ready.
    • Desktop logs repeatedly report app_start outcome=failure with reason=timeout after about 121 seconds.
    • Logs also show in_app_updates_policy_timeout after the pending update-policy wait.
    • Account lookup and pub/sub can succeed, and the CLI has a healthy WebSocket connection, so this is Desktop-specific.
    • Earlier logs also showed Desktop network policy errors for /wham/tasks/list and /wham/usage, plus token_revoked from a stale cached token. Reauthentication removed the token_revoked errors, but the cold-start spinner remains.

    Reproduction and tests:

    • Reproduces after closing and reopening the app.
    • Updating the CLI, installing the latest Desktop package, Store cache reset, AppX re-registration, profile/cache reset, and ChatGPT reauthentication did not make cold launch reliable.
    • Killing only the child codex.exe app-server process causes the existing ChatGPT window to recover within seconds; the main window and local data remain intact.

    Request:
    Please investigate the Windows Desktop app-server startup/update-policy/renderer readiness path for 26.924.2738.0 and provide an official fix or supported workaround. No credentials, account IDs, project paths, or raw logs are included here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingcomputer-useperformancewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions