Windows Desktop intermittently fails atomic global-state rename with EPERM and leaves large temp files

Environment

• Codex Desktop: OpenAI.Codex 26.825.5331.0
• Bundled CLI: codex-cli 0.151.0-alpha.7.1
• Windows 11 x64 (10.0.26200)

What happens

Desktop intermittently logs:

[global-state] Failed to persist global state
errorCode=EPERM
errorMessage="EPERM: operation not permitted, rename '...\.codex\..codex-global-state.json.tmp-<id>' -> '...\.codex\.codex-global-state.json'"

This is not a single startup event. A scan of the retained Codex Desktop logs on this machine found:

• 19 Failed to persist global state events;
• 19/19 are EPERM failures on the atomic rename into .codex-global-state.json;
• failures span multiple Desktop sessions/build periods from August 15 through August 29;
• the current August 29 Desktop session logged three failures at 12:22:36Z, 15:08:03Z, and 15:13:17Z.

The destination file is eventually writable and continues to update, so this is intermittent rather than a permanently invalid ACL/path.

Residue

The failed writes also leave abandoned atomic-write files under %USERPROFILE%\.codex.

At the time of inspection there were 8 ..codex-global-state.json.tmp-* files remaining. The newest two were approximately:

• 2.5 MiB
• 1.5 MiB

Several older zero-byte temp files also remained.

The live .codex-global-state.json exists, is owned by the current user, and had been successfully updated after the latest logged failure.

Expected behavior

Atomic global-state persistence should tolerate transient Windows rename contention and should not leave abandoned temp generations behind.

Potentially appropriate behavior would be a bounded retry/backoff for Windows sharing/rename contention plus exact-temp cleanup once a write is no longer recoverable, while preserving fail-closed behavior for genuine permission errors.

Reproduction / diagnostics

This is intermittent, but the retained logs make it measurable:

1. Use Codex Desktop normally on Windows over multiple sessions.
2. Search Desktop logs for Failed to persist global state.
3. Observe EPERM on rename from ..codex-global-state.json.tmp-* to .codex-global-state.json.
4. Inspect %USERPROFILE%\.codex for stale ..codex-global-state.json.tmp-* generations.

No model/provider inference is needed to inspect the failure.

Related issue

#32727 concerns a first-launch ENOENT around .codex-global-state.json.tmp. This report is different: Desktop is already initialized and operational, the destination state file exists and is later updated successfully, but atomic replacement intermittently fails with EPERM and leaves residue.

Start by tracing the global-state persistence path that creates ..codex-global-state.json.tmp-* and renames it to .codex-global-state.json; correlate it with the retained Desktop logs and inspect %USERPROFILE%\.codex residue. Done means transient Windows rename contention is bounded and recoverable, unrecoverable writes clean up their exact temp file, and genuine permission failures still fail closed.