openai / openai/codex

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

Open
#39,132 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug performance windows-os
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the PowerShell diagnostic command and the Codex logs under %LOCALAPPDATA%\Packages\OpenAI.Codex_\LocalCache\Local\Codex\Logs\YYYY\MM\DD. Compare the idle CPU/thread behavior with issues #20214, #31531, #30527, and #38765, while treating the git timings as a symptom. Done requires identifying the spin's cause and validating that idle ChatGPT.exe processes no longer accumulate CPU or hang.

Written by the indexing model from the issue text.

Assessment

Tech stack
electron, git, powershell
Domain
desktop, operating-systems, performance
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.