Skip to content

[Windows] Primary runtime updater re-downloads 501.8 MB hourly after non-retryable EPERM activation failure #40182

Open
Open
[Windows] Primary runtime updater re-downloads 501.8 MB hourly after non-retryable EPERM activation failure#40182
Labels
appIssues related to the Codex desktop appbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)windows-osIssues related to Codex on Windows systems

Description

@jan013013
jan013013
opened on Aug 23, 2026

What version of the Codex App are you using?

  • Current Windows Store package: OpenAI.Codex 26.818.5229.0 (x64)
  • The repeated failures were logged by package build 26.814.5167.0
  • Codex CLI: 0.147.0
  • Primary runtime bundle requested: 26.819.11345

What platform is your computer?

Windows 11 Pro x64, version 10.0.26200 (build 26200).

What issue are you seeing?

The Codex desktop primary-runtime updater downloaded the same 501,849,919-byte archive from persistent.oaistatic.com approximately once per hour after every activation failure.

The download URL was:

https://persistent.oaistatic.com/codex-primary-runtime/26.819.11345/codex-primary-runtime-win32-x64-26.819.11345.tar.gz

Local log analysis found:

  • First attempt: 2026-08-19 08:37:52 local time
  • Successful completion: 2026-08-23 11:48:03 local time
  • 101 scheduled attempts in roughly 4 days
  • 96 complete archive downloads followed by activation failure
  • 4 network-stage failures
  • 1 eventual success
  • At least 48.678 GB of confirmed traffic from complete archive downloads alone

The repeated error was:

[primary-runtime-installer] primary_runtime_bundle_install_outcome
errorCategory=permission_denied
errorCode=EPERM
failureStage=activate_runtime
outcome=failed
retryable=false
trigger=scheduled_update
errorMessage="EPERM: operation not permitted, rename '%USERPROFILE%\.cache\codex-runtimes\codex-primary-runtime' -> '...previous-<uuid>'"

The current runtime directory contained executables being used by Codex. Windows therefore refused the directory rename. That part is expected Windows file-lock behavior. The bandwidth-consumption problem is that Codex deleted the staging directory (including the fully downloaded, verified archive) after the non-retryable activation failure, then the hourly scheduler downloaded the identical 501.8 MB archive again.

This happened silently, with no user notification or visible bandwidth warning.

What steps can reproduce the bug?

  1. Run Codex Desktop on Windows with the current primary runtime actively in use.
  2. Make a newer primary runtime bundle available to the hourly scheduled updater.
  3. Allow the 501.8 MB bundle to download.
  4. Let activation attempt to rename the active codex-primary-runtime directory.
  5. Observe EPERM at failureStage=activate_runtime.
  6. Leave Codex running.
  7. Observe another full download on the next hourly scheduled check, despite retryable=false.

What is the expected behavior?

After a complete bundle download and a non-retryable activation failure, Codex should not discard the verified archive and download it again every hour.

Any of the following would prevent the traffic loop:

  • retain the verified archive and activate it after Codex exits/restarts;
  • defer activation when the current runtime has live processes;
  • stop automatic retries after a non-retryable error;
  • use exponential backoff and a retry/traffic cap;
  • notify the user and offer “restart to finish update”;
  • respect metered-network settings.

At minimum, one failed 500 MB update must not become an unbounded hourly re-download loop.

Additional information

No raw log files are attached because they can contain local paths and session details. The counts above were derived from the local Codex desktop logs and the archive size was verified from the HTTP response.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Aug 23, 2026

  2. github-actions commented on Aug 23, 2026

    @github-actions
    github-actionsBot
    on Aug 23, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. jan013013 commented on Aug 23, 2026

    @jan013013
    jan013013
    on Aug 23, 2026 – with ChatGPT Codex Connector
    Author

    I reviewed #38999. It is related to primary-runtime installation on Windows, but the failure mode and impact here are distinct: the runtime was present, each verified 501.8 MB payload was discarded after a retryable=false activation failure, and the scheduler downloaded it again hourly, producing at least 48.678 GB of traffic. This report is specifically about the unbounded re-download loop and missing backoff/cache/restart handling.

  4. zemeng5208 commented on Aug 23, 2026

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

    This is a good match for one narrow Windows-local failure mode I’ve been tracking. I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

    For this issue, the part WinBridge may help with is diagnosing the local activation blocker, not the updater’s hourly retry policy itself. In particular, an EPERM on

    rename %USERPROFILE%\.cache\codex-runtimes\codex-primary-runtime -> ...previous-<uuid>

    is consistent with Windows still having one or more executables/DLLs under the active runtime tree mapped by a live or stale Codex/helper process. WinBridge’s local diagnostics are intended to identify this class of file-lock / runtime-helper ownership problem and distinguish it from cache/version/staging drift before attempting recovery.

    A useful separation here is:

    • Local layer WinBridge can help diagnose/recover: stale helper/runtime processes holding the current runtime directory, inconsistent user-side runtime staging/version state, or a partially activated local runtime after a failed rename.
    • Upstream behavior WinBridge cannot fix: Codex deleting a verified ~501.8 MB staged bundle after retryable=false, scheduling another full download every hour, or failing to defer activation until the owning processes exit. That retry/cache policy needs an OpenAI-side fix.

    I would also avoid deleting the active runtime directory manually while Codex is running; on Windows that can turn a clean lock failure into a partially staged state. WinBridge does not modify WindowsApps, and I would not expect it to guarantee a fix if the only problem is the updater lifecycle/backoff logic.

    The fact that your final attempt eventually succeeded is also useful evidence: it makes a persistent package-corruption explanation less likely and is consistent with the blocking handle eventually disappearing.

  5. scroner888-ux commented on Aug 25, 2026

    @scroner888-ux
    scroner888-ux
    on Aug 25, 2026

    This looks like the same underlying issue as #40455 (which I opened independently, before finding this one). My report approaches it from a different angle — network-level packet capture rather than internal error logs — but points to the exact same subsystem and even the same bundle version (26.819.11345).

    Adding a few things that might help narrow this down further:

    1. Confirmed to also trigger on cold launch, not just the hourly background scheduler — I never left the app running for an hour; the ~400MB burst happens within the first 15 seconds of every fresh start (measured via pktmon, deduplicated by PktGroupId+PktNumber to rule out double-counting across NDIS capture points).
    2. DNS correlation: persistent.oaistatic.com resolves to two A records (104.18.32.47, 172.64.155.209); together they accounted for 98.9% of all captured traffic in a 63-second launch window.
    3. Reproduced across two consecutive Store updates (26.818.3698.0 → 26.818.8289.0) — so this isn't specific to one build. If the EPERM/rename-on-active-runtime root cause you found is accurate, that would explain why updating the app version alone doesn't fix it: the lock condition (runtime files in use by the running process) would still apply on the new build too.

    Given this, this bug seems to affect anyone who either keeps the app open long-term (hourly loop, as you found) or restarts it frequently (per-launch loop, as I found) — same root cause, different observed cadence. Closing my duplicate (#40455) and linking here.

  6. scroner888-ux
    marked [Windows] Desktop app re-downloads ~400MB from persistent.oaistatic.com on every cold launch, reproduced on 2 different app versions #40455 as a duplicate of this issue on Aug 25, 2026

  7. wakare commented on Aug 28, 2026

    @wakare
    wakare
    on Aug 28, 2026 – with ChatGPT Codex Connector

    Independent confirmation on Windows 11 x64. I am not attaching raw logs because they may contain local paths and session details.

    Environment

    • Codex Windows package: OpenAI.Codex_26.818.2441.0_x64__2p2nqsd0c76g0
    • Previously installed primary runtime: 26.813.12317
    • Runtime update target: 26.826.12353

    Network observations

    A local per-process/per-destination traffic collector observed:

    • about 3.79 GiB attributed to the Codex desktop executable over an approximately 8-hour capture window;
    • about 3.75 GiB of that traffic downloaded from persistent.oaistatic.com;
    • near-hourly bursts of approximately 503,300,000 bytes (~480 MiB) each;
    • at least 25 failed scheduled update attempts in approximately 24 hours in the desktop logs.

    The requested archive was:

    https://persistent.oaistatic.com/codex-primary-runtime/26.826.12353/codex-primary-runtime-win32-x64-26.826.12353.tar.gz

    Sanitized failure signature

    trigger=scheduled_update
bundleVersion=26.826.12353
errorCategory=permission_denied
errorCode=EPERM
failureStage=activate_runtime
outcome=failed
retryable=false
errorMessage="EPERM: operation not permitted, rename
'C:\Users\<redacted>\.cache\codex-runtimes\codex-primary-runtime'
-> '...codex-primary-runtime.previous-<redacted>'"

    Process inspection showed a long-lived bundled pwsh.exe running from inside:

    C:\Users\<redacted>\.cache\codex-runtimes\codex-primary-runtime\dependencies\native\powershell\pwsh.exe

    It was a child of the Codex process. Because the executable being used is inside the directory that activation tries to rename, this is consistent with Windows denying the rename while the old runtime is still mapped by a live helper process.

    This independently reproduces the same updater loop with a newer runtime target (26.826.12353). The important upstream issue is still the same: after a completed download and a retryable=false activation failure, the verified archive is not reused and the full payload is downloaded again on the next scheduled attempt. The updater should coordinate helper shutdown, defer activation until restart, retain the verified archive, and/or stop retrying the full download.

  8. abdulramonjemil commented on Aug 28, 2026

    @abdulramonjemil
    abdulramonjemil
    on Aug 28, 2026

    Now running into the same issue. Any reliable workarounds???

  9. scroner888-ux commented on Sep 1, 2026

    @scroner888-ux
    scroner888-ux
    on Sep 1, 2026

    Independent confirmation on version 26.825.6671.0 (updated today via Microsoft Store, triggered by the same re-download loop this issue describes).

    Measured via Resource Monitor across two consecutive cold launches, ~1 minute apart, full close via tray between them:

    • Launch 1: codex.exe 613 KB/s, ChatGPT.exe 179 KB/s (~792 KB/s combined)
    • Launch 2: codex.exe 1019 KB/s, ChatGPT.exe 473 KB/s (~1.49 MB/s combined) — higher than launch 1, not lower

    This rules out "it's just the first-run download" as an explanation — the second launch was worse than the first, consistent with the activation failure described here causing the verified archive to be discarded and re-fetched (and possibly triggering additional requests, as several new remote endpoints appeared on the second launch that weren't present on the first).

  10. railgun20001 commented on Sep 23, 2026

    @railgun20001
    railgun20001
    on Sep 23, 2026

    I hit the same Windows primary-runtime updater failure: repeated downloads followed by failureStage=activate_runtime, errorCode=EPERM while renaming %USERPROFILE%\.cache\codex-runtimes\codex-primary-runtime to a .previous-* directory. This was on Codex Desktop 26.917.6896.0, updating the runtime from 26.826.12353 to 26.905.11957.

    A Sysinternals Handle scan found two Code.exe (VS Code) processes holding a handle to codex-primary-runtime\dependencies\native\poppler\Library\bin. After I closed VS Code, a later scan found a bundled pwsh.exe holding DLLs under the same runtime; its parent was codex.exe. So VS Code can be one active consumer of the runtime, and Codex-launched shells can keep it in use too.

    Workaround that succeeded here: save work and fully close VS Code, restart Codex, then wait for the runtime update to finish. I did not need to delete the cache or manually rename the runtime. The subsequent install logged outcome=installed for 26.905.11957; executable probes and runtime validation passed with problemCount=0. A later dependency diagnosis reported installed=true, problemCount=0, and the active runtime.json now reports 26.905.11957.

    If you still see EPERM, run Sysinternals Handle as administrator and search for codex-primary-runtime to identify current holders before retrying. Run the scan from a system PowerShell outside Codex: a PowerShell executable bundled inside the runtime will itself show up as a holder.

    This is a local workaround for the activation/rename failure, not a fix for the updater discarding a verified download and fetching it again after a non-retryable failure. I also cannot infer from this result that it fixes the separate desktop crash symptoms reported elsewhere.

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 workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)windows-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