[Windows] System-wide stutter while Codex is idle; fully exiting app immediately restores OS responsiveness

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

What version of the Codex App are you using?

26.810.50856 — Powered by Codex & OWL, released 2026-08-14.

What issue are you seeing?

Codex Desktop causes severe system-wide stuttering on Windows even when there are no active Codex tasks running.

While the app is open, Windows interaction becomes choppy/jerky. Fully closing Codex immediately restores normal OS responsiveness.

This appears closely related to current reports #38716, #38551, #38698, #38710, and #33074. In particular, #38698 reports the same 26.810.50856 build and the same system-wide stuttering/recovery after exiting Codex. This report additionally documents an idle-state reproduction: no Codex task needs to be executing for the system-wide lag to occur.

Observed resource usage

A Task Manager capture during the affected state showed approximately:

  • Total system CPU: 13%
  • Memory: 59%
  • Disk: 0%
  • Codex process: ~8.5% CPU and ~540 MB RAM
  • Additional Codex/codex.exe processes were present

The machine was therefore not under general CPU, RAM, or disk saturation.

Steps to reproduce

  1. Launch Codex Desktop 26.810.50856 on Windows.
  2. Do not run any Codex task / leave Codex idle.
  3. Use Windows normally and observe system-wide stuttering/jerky responsiveness.
  4. Fully exit Codex.
  5. Windows responsiveness immediately returns to normal.

Expected behavior

When Codex has no active tasks, background resource usage should remain bounded and the app should not affect mouse/input/UI responsiveness across the operating system.

Actual behavior

The entire OS becomes noticeably jerky while Codex is open, despite low overall system utilization. Fully exiting Codex reliably resolves the problem.

Additional information

A screenshot of Task Manager was captured showing the affected state. It is not attached here to avoid exposing unrelated local process information, but the relevant measurements are summarized above.

The issue was observed on 2026-08-15, one day after the reported release date of build 26.810.50856. Exact Windows build is not yet captured.

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 13 days ago

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

  • #38723
  • #38719
  • #38745
  • #38716
  • #38698

Powered by Codex Action

kaigendev · 13 days ago

Additional affected-system hardware information:

  • CPU: AMD Ryzen 9 5950X, 16 cores, 3.40 GHz
  • RAM: 64 GB
  • Architecture: x64 / 64-bit Windows

This further rules out obvious resource-capacity limitations: the system-wide stutter occurs on a 16-core Ryzen 9 / 64 GB machine while Task Manager shows only ~13% total CPU and 59% memory usage.

For privacy, device name, Windows device ID, and product ID have intentionally not been included in this public issue.

Exact Windows edition/version/build is still to be captured.

kaigendev · 13 days ago

Windows version confirmed for the affected system:

  • Edition: Windows 11 Enterprise
  • Version: 23H2
  • OS build: 22631.7517
  • Windows Feature Experience Pack: 1000.22700.1108.0
  • Architecture: x64

Combined affected environment now documented:

  • Codex Desktop: 26.810.50856 (released 2026-08-14)
  • Windows 11 Enterprise 23H2, build 22631.7517
  • AMD Ryzen 9 5950X (16 cores)
  • 64 GB RAM

This is useful because several related reports are on Windows build 26200; this reproduction confirms the same system-wide stutter behavior on the older 22631/23H2 branch as well.

chenjunyan1 · 12 days ago
kaigendev · 12 days ago

Additional A/B diagnostic result: Pet is disabled on the affected system.

The system-wide stutter still occurs with Pet disabled, so this reproduction does not appear to be the Pet/overlay-specific case described in #38663. That narrows the issue toward the other 26.810.50856 idle/background regressions (for example #38698 / #38716).

eliotcougar · 12 days ago

Opening and then closing the pet seems to be solving the stutter temporarily.

Wilsman · 12 days ago
Opening and then closing the pet seems to be solving the stutter temporarily.

this completely fixes the stutter for me

kaigendev · 12 days ago

Additional WPR/WPA data from an affected session (Codex/ChatGPT Desktop 26.810.50856):

  • The main desktop process ChatGPT.exe <OpenAI.Codex> (PID 12536) accumulated 32.83 s of sampled CPU during the trace.
  • Of that, 22.29 s had unavailable stacks (n/a), while 10.55 s had resolved stack roots.
  • Of the resolved portion, approximately 10.53 s (~99.8%) traverses chrome.dll, through both direct Chromium frames and ntdll.dll -> kernel32.dll -> ChatGPT.exe -> chrome.dll paths.
  • codex.exe itself was negligible by comparison (about 15 ms sampled CPU in the same capture).
  • DWM, WMI, and Defender were also low relative to the main desktop process; the machine was not globally CPU-saturated.
  • Some Win32/window-manager activity is visible (win32u/win32k), but it is small compared with the sustained Chromium CPU time. NVIDIA/D3D activity is also present only in small amounts in the sampled stacks.
  • Symbols for chrome.dll were unavailable, so the exact Chromium/Electron function cannot be identified from this capture.

This strengthens the hypothesis that the stutter is caused by sustained Chromium/Electron-side background activity or a busy loop in the main desktop process rather than Codex backend work or overall system resource saturation.

I am not attaching the raw ETL publicly because it contains local paths / system details.

GatoDev · 12 days ago

THIS IS URGENT. FIX ASAP. SHOULD BE PRIORITY 1