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

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

• #38999

Powered by Codex Action

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.

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.

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.

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.