›_ Codex Issues
Codex Issues / #32516

Windows Desktop 26.707: sustained Electron main-process CPU/memory loop persists without Git

Open 💬 4 comments Opened Jul 12, 2026 by blakepi
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

Codex Desktop for Windows is unusably laggy on Microsoft Store package OpenAI.Codex 26.707.3748.0.

A multi-pass local diagnostic run found a sustained Electron/Chromium main-process background loop while the app is idle:

  • approximately 86–113% of one logical CPU core
  • private memory repeatedly cycling between roughly 0.3 and 2.4 GB
  • approximately 120,000–140,000 page faults/sec
  • approximately 500 MB/sec of logical read I/O
  • ETW measured only 151,552 bytes of physical reads over 32.45 seconds, so this is logical/cached/native churn rather than a storage bottleneck
  • a scheduler trace independently measured 95.6% of one logical core
  • the available sampled main-thread CPU was concentrated in a narrow chrome.dll RVA range; packaged symbols were unavailable

The GPU and renderer helper processes remained comparatively cold.

Background work observed

Procmon showed repeated Git snapshot commands:

  • git config --null --get core.fsmonitor
  • git status --renames --porcelain=v1 -z --untracked-files=no
  • git add -u
  • git ls-files --others --exclude-standard -z
  • git read-tree
  • git add --pathspec-from-file=- --pathspec-file-nul
  • git write-tree

It also showed repeated bundled-marketplace staging/reconciliation. These amplify the problem, but they do not appear to be the primary trigger.

Controlled tests

The main-process storm remained after each reversible control:

  • fresh logs database
  • empty session/history profile
  • 15 configured plugins disabled and memories off
  • workspace with no .git directory
  • temporary initial Git commit
  • completely clean committed repository
  • app window minimized

Representative CPU averages (% of one logical core):

| Control | CPU avg | P95 | Logical reads |
|---|---:|---:|---:|
| Initial idle | 86.32% | 118.52% | 532.7 MB/s |
| Empty history | 91.92% | 116.96% | 542.6 MB/s |
| Configured plugins disabled | 97.94% | 126.68% | 505.1 MB/s |
| No Git repository | 112.67% | 165.69% | 565.4 MB/s |
| Clean committed repository | 89.01% | 115.67% | 520.1 MB/s |

The minimized-window control still used 116.1% of one core and accumulated 7.84 GB of logical reads in 15 seconds.

Environment

  • Windows 11 x64
  • 32 GB RAM
  • 12 logical CPUs
  • ample free NVMe space
  • Microsoft Store Codex package 26.707.3748.0
  • app package status reports OK
  • Store update completed before final testing

Expected behavior

The desktop main process should become mostly idle when no task is active and should not continuously churn CPU, private memory, process metrics, Git snapshots, or logical reads.

Related reports

This appears related to #22085, #20933, #17229, #15620, and #22912. #22085 is closed as completed, but the problem still reproduces in 26.707.3748.0 and persists after removing Git from the workspace.

Additional evidence

A sanitized private support bundle is available containing derived telemetry summaries and restoration results. Raw Procmon/ETL traces, databases, sessions, config, authentication data, usernames, and local paths are intentionally not attached publicly.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #31618
  • #31531
  • #31692
  • #32097

Powered by Codex Action

nishina7-dotcom · 23 days ago

I can reproduce what appears to be the same main-process CPU/memory loop on a newer Windows package.

Environment

  • Windows 11 x64
  • Microsoft Store package: OpenAI.Codex 26.730.8199.0
  • Bundled ChatGPT.exe product version: 151.0.7922.71
  • 12 logical CPUs
  • Codex Pet disabled during the baseline test

Symptom

The desktop UI has a small but very noticeable hitch at roughly one-second intervals, including while no Codex task is running. Scrolling and general UI interaction stutter, while other Windows applications remain smooth. Agent execution and file/command work otherwise appear normal.

Measurements

I sampled each ChatGPT.exe / codex.exe process at 100 ms intervals for 12 seconds during ordinary UI interaction:

  • hot ChatGPT.exe process:
  • average CPU time: 71.1 ms per 100 ms sample (~71% of one logical core)
  • peak: 203.1 ms per 100 ms sample
  • 66 of 120 samples exceeded 50 ms CPU time
  • working set cycled between 1,119 MB and 1,939 MB
  • working-set swing: 820 MB
  • codex.exe backend:
  • average CPU time: 1.0 ms per 100 ms sample
  • working set: 141–156 MB
  • system peak during the check:
  • total CPU: 14.5%
  • physical disk time: 1.7%
  • available memory: approximately 6.1 GB

Per-second CPU time for the hot ChatGPT.exe process repeatedly ranged from roughly 400 ms to just over 1,000 ms. This aligns closely with the periodic UI hitch.

Controls already tried

None of these resolved it:

  • fully restarting the desktop app
  • restarting Windows
  • Windows app Repair
  • restarting the GPU driver
  • closing Chrome and restoring several GB of free memory
  • archiving older tasks
  • keeping Codex Pet disabled

Enabling Codex Pet makes the UI noticeably worse, but disabling it does not remove the baseline periodic hitch.

This looks localized to the Electron/Chromium/ChatGPT desktop main/UI process rather than the Codex backend, GPU saturation, disk pressure, or the workload being executed. The issue therefore appears to remain present in 26.730.8199.0.

nishina7-dotcom · 22 days ago

Follow-up / correction for my previous data point: I found a concrete local trigger, and the mitigation was decisive.

The desktop log showed a stale heartbeat automation repeatedly trying to hydrate/resume an invalid target:

  • automation kind: heartbeat
  • persisted target: target_thread_id = "current"
  • repeated errors approximately once per second:
  • thread/read -> invalid thread id
  • thread/resume -> invalid session id
  • heartbeat_automation_resume_failed
  • source: thread_hydration

After pausing that single stale automation—without deleting threads or resetting the app—a new 10-second sample of the same hot ChatGPT.exe process changed from:

  • 71.1 ms CPU per 100 ms sample to 1.6 ms
  • 66 busy samples out of 120 to 0 out of 100
  • working-set swing from 820 MB to 1 MB
  • peak sample after pausing: 46.9 ms

The user also confirmed that both the approximately one-second UI hitch and the recurring startup “Reconnecting…” delay improved after pausing the automation.

So on this machine, the sustained CPU/memory loop and periodic UI hitch were primarily caused by a malformed/stale heartbeat target being retried through thread hydration. Codex Pet amplified the UI load but was not the root trigger.

This suggests a useful additional failure mode to guard against: Desktop should validate or migrate legacy heartbeat targets such as "current", and failed heartbeat hydration should use bounded retry/backoff instead of retrying continuously. My earlier comment should not be interpreted as proof that the same loop persists in 26.730 with a clean automation state.

nextdumpling · 13 days ago

I can reproduce a closely matching regression on the current Windows package after the August 14 update

Environment

  • Windows 11 x64
  • Microsoft Store package: OpenAI.Codex 26.810.4967.0
  • Bundled ChatGPT.exe product version: 151.0.7922.137
  • 12 logical CPUs and 32 GB RAM
  • App package status: Ok

Timing and symptoms

The machine had used Codex Desktop for several months without this behavior. The package auto-updated on August 14, and the lag first appeared within roughly two hours

The app now feels laggy immediately after launch. Mouse/input responsiveness can feel degraded even though Task Manager does not show high total CPU, RAM, disk, GPU, DPC, or interrupt saturation. Restarting the app did not help, and a full Windows restart did not resolve it either

CPU and ETW evidence

A 10-second per-thread CPU delta before reboot showed the hottest thread in the main ChatGPT.exe process consuming 6.234 CPU seconds, or about 62.3% of one logical core

After the full Windows restart, a fresh 10-second sample reproduced the same pattern:

  • main ChatGPT.exe PID: 22172
  • hottest thread: 6.094 CPU seconds in 10 seconds, or 60.9% of one logical core
  • next hottest threads: approximately 14.8% and 14.7% of one core

An 8-second WPR sampled-profile trace from the earlier run recorded:

  • 21,196 total CPU samples
  • 5,399 samples on the hot main-process thread
  • 4,772 of those hot-thread samples inside the packaged chrome.dll
  • the hottest instruction addresses were concentrated in a narrow chrome.dll RVA range
  • GPU, renderer, bundled codex.exe, and Node/MCP child processes were comparatively cold

The exact packaged chrome.dll.pdb is not publicly available, so I cannot responsibly name the internal function from the RVA alone

Controls and a distinction from the stale-heartbeat report

  • the local SQLite log database passes quick_check
  • no active log-row growth was observed during a 10-second idle check
  • no matching legacy target_thread_id = "current" exists in the local heartbeat automation files
  • the log database contains no matches for heartbeat_automation_resume_failed, invalid thread id, or invalid session id

So the stale-heartbeat retry trigger described in a previous comment does not appear to explain this machine

Current hypothesis

This looks like a regression in the packaged Electron/Chromium main process that enters a sustained CPU loop or high-frequency polling path shortly after startup. The update timing is strong evidence of correlation, but without matching private symbols or an old-build A/B test I cannot claim the exact internal function or prove which feature introduced it

A sanitized ETL and derived per-thread summaries are available if a maintainer wants them