Repository navigation
Windows Desktop 26.803.5235.0: UI process sustains ~90–102% CPU while idle #37372
Description
Summary
On the current Codex/ChatGPT Windows desktop app, the main UI process continuously consumes about 90–102% of one logical CPU while the app is idle (measured over 8-second intervals with no typing). This makes both typing and task/tool execution feel sluggish. The Codex backend process remains low CPU.
This is related to #29821, #29543, and #28855, but differs in that the near-full-core UI CPU use is sustained on the current desktop package, including after a reboot and app repair/reset workflow.
Environment
- Codex desktop package:
OpenAI.Codex 26.803.5235.0 - Windows x64
- CPU: Intel Core i3-9100F (4 physical / 4 logical cores)
- Memory: 16 GB
- GPU: NVIDIA GT 1030 (2 GB)
- Power plan: Balanced; CPU clock measured at 3.6 GHz
Reproduction
- Fully reboot Windows.
- Start Codex Desktop.
- Leave the app idle for 8 seconds after launch (no typing).
- Inspect per-process CPU use.
Actual result
- The main
ChatGPT.exeUI/browser process uses approximately 90–102% of one logical CPU during idle 8-second samples. - The
codex.exebackend process remains around 0–2% CPU. - The desktop UI is visibly sluggish for composition and for task/tool interaction.
Investigation already performed
- The behavior persisted after updating to 26.803.5235.0, Windows Settings Repair, a Reset workflow, and full app restarts.
- Disk queue was about 0.01; around 5 GB memory was available; CPU queue average was about 0.6 (maximum 3). This did not indicate disk, memory, or power-throttling pressure.
- An unrelated third-party IME initially caused high
ctfmon.exeCPU. After removing that IME profile and rebooting,ctfmon.exereturned to roughly 0–2% CPU, but the Codex UI process still used about 90% of a core. This rules out the remaining lag being caused by that IME issue. - Loaded-module inspection of the UI process found no third-party security, input, or overlay DLL injection.
- A local Codex CLI session is usable as a temporary workaround, which further points to the desktop UI process.
Expected result
The desktop UI should remain near idle CPU when no interaction is occurring and should provide responsive text input and task execution.
Privacy
No conversation content, project files, usernames, local paths, screenshots, or raw diagnostic logs are attached. I can provide further sanitized measurements if requested.
Activity
github-actions commentedon Aug 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
eski7399 commentedon Aug 14, 2026
Additional reproduction on Windows Desktop build
26.810.4967.0:After today’s update, the app entered the high-CPU state immediately after restarting. Fully closing and reopening Codex cleared the behavior temporarily, but it later returned without an active task.
Observed while idle:
ChatGPT.exeprocess at 13.16 CPU-seconds, approximately 16% of an 8-logical-processor system.codex.exeapp-server andcodex-code-mode-hostremained effectively idle.Expected behavior: the desktop UI should settle near idle CPU and remain responsive after restart.
This appears to be a Windows desktop UI/main-process regression or recurring restored-state loop. No screenshots or private session data are attached.
nnatali0207-wq commentedon Aug 15, 2026
Additional reproduction on Windows Desktop build 26.810.6296.0.
Feedback ID: 01a0065c-5099-7971-b349-52a42758ceca
I am seeing the same persistent main-process CPU issue on a newer build.
The app initially works normally after restart. After approximately 3–7 completed Codex tasks, the main ChatGPT.exe process remains at approximately 30–37% total CPU indefinitely, even though the Codex task has completed and Codex child/runtime processes are effectively idle. Fully exiting and restarting the app temporarily clears the condition, but it reproduces again after several completed tasks.
The issue was first noticed immediately after the August 14, 2026 desktop app update.
Windows App Repair and App Reset did not resolve it.
I captured the defective state with ETW/WPR. In the primary trace:
Windows Error Reporting also recorded RADAR_PRE_LEAK_64 for ChatGPT.exe. Application logs contained repeated ResizeObserver loop errors and unknown-conversation turn lifecycle errors; these are correlated findings only, not claimed as the proven root cause.
A private diagnostic package containing two ETW traces, tracerpt analysis, SHA-256 verification, technical reports, and redacted log excerpts is available to OpenAI engineering/support if useful.