[Windows][Desktop 26.803.10989.0] Reproducible idle CPU spin in main + renderer — not memory pressure, not filesystem

Same symptom on Windows 11 Pro. I reproduced it twice under different system
conditions and got thread-level detail that may narrow it down.

Environment

• Windows 11 Pro 10.0.26200, 16 logical cores, 31.2 GB RAM
• Codex package OpenAI.Codex 26.803.10989.0
• Binary is ChatGPT.exe, FileVersion 151.0.7922.76

(Note: I've seen 26.810.7004.0 referenced in other issues, but the Store has not
offered it to me yet, so I can't confirm whether this persists on that build.)

Symptom

Codex burns ~200% of one core while completely idle — no prompt running, window
unfocused, nothing typed. Eventually the UI stops repainting and Windows logs an
Application Hang for ChatGPT.exe.

Thread-level detail

This is not work spread across threads. It is exactly one thread per process stuck
in Running state at AboveNormal priority, while every other thread in those
processes sits in a normal Wait.

Reproduction 1 — uptime 103 h, committed memory 83%:

| Process | Thread | CPU accumulated | State |
|---|---|---|---|
| main | 62388 | 925 s | Running, AboveNormal |
| renderer | 83320 | 611 s | Running, AboveNormal |

Total burned before I killed the tree: 3,441 CPU-seconds (~57 min of core time).
Onset roughly 20 minutes after a clean launch.

Reproduction 2 — after a reboot, uptime 14 h, committed memory 44.6%, 12.9 GB free:

| Process | Thread | CPU accumulated | State |
|---|---|---|---|
| main | 31116 | 1187 s | Running, AboveNormal |
| renderer | 44940 | 157 s | Running, AboveNormal |

Live sample: 196% of one core across the process group. Onset 37 minutes
after a clean launch. Window still reported Responding: True at this point — it
burns two cores for a while before it visibly locks up.

Memory pressure is NOT the trigger

I initially assumed the spin was provoked by sustained memory pressure. It isn't.
Reproduction 2 happened on a freshly rebooted machine at 44.6% commit with 12.9 GB
free — half the pressure of reproduction 1, same fingerprint. Whatever the loop is,
it arises on a healthy system.

Control on the same machine

ChatGPT Classic.exe (the ChatGPT desktop app, same Electron generation), running
concurrently: 1.1% of one core, zero threads in Running state, 5 processes,
444 MB. So this is Codex-specific, not Electron-on-this-machine.

One red herring worth flagging

Codex's own logs report git config --get remote.origin.url taking avg 3053 ms
(max 7882 ms; 11,441 of 11,820 calls over 500 ms). That looks like slow disk or cloud
sync interference. It is not.

Timing the identical command directly on the same machine:

• repo on a OneDrive-backed path: ~29 ms
• repo on a plain local path: ~29 ms
• git --version (bare process-launch floor): 27 ms

Identical, and almost entirely process-launch overhead. The inflated durationMs is
measured inside the JS event loop, and Codex fires ~23 workspace scans concurrently
(their startTimeMs values cluster within ~700 ms). With the main thread pinned, the
completion callbacks can't be serviced, so the reported duration inflates ~100x.

The slow git timings are a symptom of the spin, not a cause. Worth not chasing
filesystem/OneDrive explanations on the strength of that telemetry.

Also

142 repeated 404s against 9 distinct dead agent_automation/{id} IDs being
re-fetched. Probably unrelated, but it is pointless traffic.

Diagnostic command

Run at a PowerShell prompt. No output means healthy; any row is the bug:

Get-Process ChatGPT | %{ $p=$_.Id; $_.Threads | ?{$_.ThreadState -eq 'Running'} |
%{ [pscustomobject]@{PID=$p;Thread=$_.Id;
CPU_s=[math]::Round($_.TotalProcessorTime.TotalSeconds,1);
Prio=$_.PriorityLevel} } }

The CPU_s value is what distinguishes a genuine spin from a momentary sample — in
both reproductions the main thread had accumulated over half the process's entire
wall-clock lifetime.

Note on Windows log location

On Windows the Codex logs live under

%LOCALAPPDATA%\Packages\OpenAI.Codex_<pkgid>\LocalCache\Local\Codex\Logs\YYYY\MM\DD

The troubleshooting docs only document the macOS path.

Possibly related

#20214, #31531, #30527, #38765, discussion #29949