›_ Codex Issues
Codex Issues / #37372

Windows Desktop 26.803.5235.0: UI process sustains ~90–102% CPU while idle

Open 💬 3 comments Opened Aug 7, 2026 by chong-linhu
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  1. Fully reboot Windows.
  2. Start Codex Desktop.
  3. Leave the app idle for 8 seconds after launch (no typing).
  4. Inspect per-process CPU use.

Actual result

  • The main ChatGPT.exe UI/browser process uses approximately 90–102% of one logical CPU during idle 8-second samples.
  • The codex.exe backend 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.exe CPU. After removing that IME profile and rebooting, ctfmon.exe returned 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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 21 days ago

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

  • #36752

Powered by Codex Action

eski7399 · 14 days ago

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:

  • Task Manager showed approximately 18% total CPU and about 1.7 GB process-group memory.
  • A local 10-second sample measured the main ChatGPT.exe process at 13.16 CPU-seconds, approximately 16% of an 8-logical-processor system.
  • The codex.exe app-server and codex-code-mode-host remained effectively idle.
  • The behavior persisted while the Codex window was not foreground.
  • Memory fluctuated around 2.4–2.7 GB for the process group; sustained growth was not established.

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 · 12 days ago

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:

  • approximately 64.6% of sampled CPU records belonged to the main ChatGPT.exe process;
  • one dominant thread accounted for approximately half of that process's samples;
  • approximately 68% of that thread's sampled instruction pointers were inside chrome.dll;
  • the same hot thread/path remained active throughout the trace while Codex runtime children were idle.

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.