›_ Codex Issues
Codex Issues / #38719

[Windows App 26.810.6296.0] Idle ChatGPT.exe loop causes system-wide cursor stutter after Aug 15 update

Open 💬 12 comments Opened Aug 15, 2026 by DrahcirHere
💡 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 (From “About Codex” dialog)?

26.810.6296.0

What subscription do you have?

ChatGPT Pro ($200/month)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64Windows 11 Home Single LanguageAMD Ryzen 9 8940HX — 16 cores / 32 logical processors15.1 GB RAMNVIDIA GeForce RTX 5060 Laptop GPUAMD Radeon 610MDisplays: 3440x1440 + 3440x1440 + 1920x1200, all at 60 Hz

What issue are you seeing?

This is a severe Windows performance regression that began immediately after a recent Codex App update.

Before the update, Codex worked normally on this computer. I could keep Codex open alongside multiple Chrome tabs and continue using Windows without mouse or touchpad stuttering.

Running several active Codex sessions could understandably slow the computer somewhat because it has 16 GB of RAM, but it did not previously cause the pointer to stop, jump, or freeze repeatedly.

The regression began after the update from 26.803.10989.0 to 26.810.4967.0 at approximately 07:10 on August 15, 2026 (Asia/Manila). It remains present after another update to 26.810.6296.0 at approximately 08:59.

The stutter now occurs under a very light workload:

  • No Codex task or session is actively generating anything.
  • Only one browser is open.
  • Moving the pointer feels like it repeatedly stops for milliseconds or longer, similar to driving over frequent speed bumps.
  • The same behavior occurs with both an external wireless mouse and the built-in ELAN touchpad.
  • The stutter affects Windows generally, not only the Codex window.
  • Hiding the app with Win+D does not stop the main ChatGPT.exe CPU loop.
  • Restarting the computer reduced memory usage temporarily but did not eliminate the CPU loop or input stutter.

Performance measurements taken while moving the pointer:

  • Main ChatGPT.exe process averaged approximately 151% of one logical CPU core and peaked at approximately 209%.
  • Windows System process used approximately 95.5% of one logical core.
  • Desktop Window Manager used approximately 16.7% of one logical core.
  • Total system CPU was approximately 12.2%.
  • Desktop Window Manager GPU usage averaged approximately 9.9% and peaked at approximately 16.1%.

Measurements with the application hidden using Win+D:

  • Main ChatGPT.exe remained at approximately 153.8% of one logical CPU core.
  • System decreased to approximately 10.8% of one logical core.
  • Desktop Window Manager decreased to approximately 3.7%.
  • Total system CPU decreased to approximately 7.2%.
  • Desktop Window Manager GPU usage decreased to approximately 0.6%.

This indicates that hiding the application reduces the additional Windows composition workload, but the primary ChatGPT.exe background loop remains active.

Task Manager grouped the application as “ChatGPT (12).” The group contained ten ChatGPT.exe shell/renderer processes, codex.exe app-server, and the code-mode host. The separate Node.js runtimes were not included in that Task Manager group.

This behavior did not occur before the 26.810.x updates, even during substantially heavier normal use.

What steps can reproduce the bug?

  1. Install or update the Windows Codex App to 26.810.4967.0 or 26.810.6296.0.
  2. Launch the application.
  3. Leave all Codex tasks idle, with no task actively generating.
  4. Use Windows normally with only one browser open.
  5. Move the pointer continuously across the desktop using a wireless mouse.
  6. Observe repeated pointer and UI stutters.
  7. Repeat using the built-in touchpad and observe the same stutter.
  8. Open Task Manager or Windows performance counters.
  9. Observe the main ChatGPT.exe process continuously consuming approximately 1.5–2 logical CPU cores while apparently idle.
  10. Hide the application using Win+D.
  11. Observe that Desktop Window Manager and System load decrease, but the main ChatGPT.exe process remains CPU-bound and the system-wide stutter can continue.
  12. Restart Windows, reopen the application, and observe that the problem returns despite the reduced post-reboot memory usage.

No mouse-specific reproduction steps, active task, prompt, or session are required.

What is the expected behavior?

An idle Codex App should use minimal CPU and must not cause system-wide pointer, keyboard, rendering, or UI stalls.

The computer should remain usable with Codex open alongside ordinary applications and multiple browser tabs, as it did before the 26.810.x updates.

Any local-history migration, indexing, SQLite maintenance, Git scanning, scheduled-task reconciliation, renderer polling, or background synchronization should be lazy, rate-limited, cancellable, and suspended or substantially reduced while the application is idle or hidden.

Large histories or workspaces should not result in an unbounded CPU loop. The application should offer safe handling, progress reporting, or a recovery mode when local state requires maintenance.

Additional information

Input and hardware checks:

  • Both the external wireless mouse and built-in ELAN touchpad are present and report status OK.
  • No HID, touchpad, mouse, USB, GPU, or storage device errors were detected.
  • DPC and interrupt activity remained low during testing.
  • Disk queue activity was modest.
  • The identical behavior across two independent pointing devices indicates this is system/UI frame pacing rather than a defective mouse.

Process and reboot comparison:

Before reboot:

  • 10 ChatGPT.exe processes
  • 1 codex.exe process
  • 16 Node runtime processes
  • Approximately 3.2 GB aggregate private memory
  • Approximately 2.3 GB free system RAM

After reboot:

  • 10 ChatGPT.exe processes
  • 1 codex.exe process
  • 10 Node runtime processes
  • ChatGPT application group used approximately 2.5 GB
  • Memory availability improved, but the idle CPU loop and cursor stutter remained

Task Manager screenshot measurement:

  • ChatGPT (12): 6.8% of total system CPU
  • Memory: 2,513.8 MB
  • Disk: 1.9 MB/s
  • Network: 0.3 Mbps
  • Overall system: 9% CPU and 64% memory

Local-state measurements, with paths and contents redacted:

  • 889 session JSONL files totaling approximately 27.15 GB
  • 158 session files larger than 50 MB
  • 8 session files larger than 500 MB
  • Local logs SQLite database approximately 1.45 GB
  • Local application-state SQLite database approximately 68.56 MB
  • Current Git workspace contains approximately 13,642 untracked files
  • 12 schedules active and 2 paused
  • Seven scheduled/background sessions ran between approximately 06:10 and 08:00 on August 15, but all had completed

These local-state measurements are included because they could expose or amplify an unbounded history migration, SQLite maintenance operation, Git scan, background polling loop, or renderer/main-process communication problem.

They are not being presented as proof of the root cause. Much of this local state predates the regression, and earlier Codex releases remained usable with substantially heavier foreground workloads.

Closely related Codex issue reports:

Windows freeze and unreliable mouse/keyboard with approximately 26.54 GB of session history and large logs. This is extremely close to the 27.15 GB history and 1.45 GB logs measured here.

Open Windows report where an idle visible app consumes approximately one CPU core. The reporter measured peaks near 144% of one logical core, close to the approximately 151–209% measured here.

Windows report concerning per-thread history or MCP replay behavior.

Large untracked workspaces causing heavy GUI Git snapshot or hashing activity.

Empty or broad Git workspaces causing repeated scanner activity and Windows Defender interaction.

Recent report involving a runaway Git-related loop.

Same-period Windows community reports:

August 14 report describing approximately 5 Hz cursor movement and half-second stutters on multiple Windows systems.

August 14 report describing ChatGPT.exe using 15–40% CPU while idle, cursor skipping, and restart providing only temporary relief.

Additional Windows stuttering report with August 14–15 confirmations following the latest update.

These community reports do not independently prove that every user has the same underlying cause. However, their timing and closely matching symptoms strongly indicate a regression in the recent Windows application updates rather than an isolated pointing-device problem.

Please investigate changes introduced in the 26.810.x Windows releases involving:

  • Main-process polling or event loops
  • Renderer/main-process communication
  • Local-history migration or replay
  • SQLite maintenance and log retention
  • Git repository scanning and automatic snapshots
  • Scheduled-task reconciliation
  • Background work that continues while no task is active
  • Work that continues while the application is hidden

<img width="820" height="914" alt="Image" src="https://github.com/user-attachments/assets/5ba3a364-3a51-4335-8e54-5d0b6487a4af" />

View original on GitHub ↗

12 Comments

github-actions[bot] contributor · 13 days ago

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

  • #38716
  • #38547
  • #38551
  • #38711
  • #38710

Powered by Codex Action

DrahcirHere · 13 days ago

Update availability status — August 15, 2026 (Asia/Manila)

This Windows 11 computer remains on Codex/ChatGPT Desktop 26.810.6296.0.

Help → Check for updates currently reports: “ChatGPT update is becoming available. Please try again later.”

Build 26.810.7004.0, which was identified as containing the expected fix, is not yet available to this device through the application update flow.

The system-wide cursor stutter therefore remains reproducible on 26.810.6296.0. I will test again as soon as 26.810.7004.0 reaches this device and report whether it resolves the problem.

AuggyH · 13 days ago

I can independently reproduce this on substantially different hardware after updating to Codex App 26.810.6296.0.

Behavior

  • After a Windows reboot, pointer movement is normal.
  • Launching Codex triggers noticeable pointer frame drops/stuttering.
  • The stutter is system-wide, including inside other applications, not only in the Codex window.
  • Rebooting restores normal pointer movement, but launching Codex again triggers the problem again.
  • This started after updating to the latest Codex App build.

Environment

  • Codex App: 26.810.6296.0 (x64)
  • OS: Windows 11 Home, build 26200, x64
  • CPU: Intel Core i7-14700KF (20 cores / 28 logical processors)
  • RAM: 64 GB
  • GPU: NVIDIA GeForce RTX 4080 SUPER, driver 32.0.15.9186
  • Display: 3840×2160 at 59/60 Hz
  • Also installed: Oray virtual display driver 17.50.19.949

Pointing device and driver

  • Mouse: Razer DeathAdder V2 X HyperSpeed
  • Connection: 2.4 GHz wireless via USB receiver (Windows PnP parent is a USB HID input device)
  • Generic hardware ID: VID_1532&PID_009C
  • PnP status: OK
  • Mouse driver provider: Razer Inc.
  • Mouse driver version: 10.0.15063.0 (2022-08-03)
  • Razer Synapse / Chroma: 4.0.698

No device-instance serial or user-specific path is included above.

Process evidence

During an 8-second sample while the problem was present, one main ChatGPT.exe process consumed approximately 134.9% of one logical CPU core (4.82% total CPU across 28 logical processors) and used about 800 MB working set. The other ChatGPT/Codex helper processes were mostly idle during that sample.

This matches the system-wide cursor stutter and persistent main-process CPU loop described in this issue, while ruling out a low-spec machine and adding a USB-receiver Razer mouse configuration.

jxtyq69 · 13 days ago

I started experiencing this issue right after updating just now.
codex version : 26.810.50856
OS: windows 11 25H2 26220.9022

Ben2248 · 13 days ago

So annoying. Same issue.

n0Obcake · 12 days ago

Additional reproduction/workaround clue from another affected user:

  • They had previously seen the same system-wide mouse stutter when the desktop Pet was actively enabled.
  • After the current desktop app update, the stutter appeared even though Pet was not active.
  • Toggling Pet ON and then OFF immediately cleared the stutter.

This suggests the Pet/cursor-follow/overlay path may remain initialized or stuck in a bad state even when Pet appears disabled, and that cycling the Pet setting forces cleanup/reset of that state. This is distinct from the simpler case where disabling an actively visible Pet fixes the problem.

Potential diagnostic angle: compare Pet/overlay/cursor polling lifecycle state before and after an ON→OFF toggle, especially after app update/migration or startup with Pet configured inactive.

manucuervodj · 12 days ago
Additional reproduction/workaround clue from another affected user: They had previously seen the same system-wide mouse stutter when the desktop Pet was actively enabled. After the current desktop app update, the stutter appeared even though Pet was not active. * Toggling Pet ON and then OFF immediately cleared the stutter. This suggests the Pet/cursor-follow/overlay path may remain initialized or stuck in a bad state even when Pet appears disabled, and that cycling the Pet setting forces cleanup/reset of that state. This is distinct from the simpler case where disabling an actively visible Pet fixes the problem. Potential diagnostic angle: compare Pet/overlay/cursor polling lifecycle state before and after an ON→OFF toggle, especially after app update/migration or startup with Pet configured inactive.

Same issue here, and I can confirm this workaround works for me as well.

The stutter returns every time I fully restart the Codex desktop app, even though Pet appears to be disabled. Toggling Pet ON and then OFF immediately fixes the system-wide mouse/cursor lag again.

So in my case this is reproducible across app restarts and strongly seems related to the Pet/overlay initialization state rather than Pet simply being visibly enabled.

WaltXinyaWang · 12 days ago

Additional Windows evidence from an independent reproduction (all task content, local paths, and account data omitted):

  • Affected package was OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0; AppX integrity and executable signature checks passed.
  • With no active Codex task and after separately closing the standalone Codex CLI, the desktop app group still sustained about 235.9% of one logical CPU core across 9 ChatGPT.exe processes (about 1.97 GB working set). The app-server was not the hot process.
  • Minimizing reduced visible composition work, but a separate controlled sample remained high: 15 samples, 114.8% min / 131.8% average / 158.6% max of one logical core. This is consistent with both a renderer/composition component and a non-visible background loop.
  • Fully exiting Codex immediately restored system responsiveness.
  • Restarting Windows did not prevent the issue from returning when Codex was reopened.
  • The behavior appeared after the 26.810.x update; earlier releases handled longer and more parallel workloads on the same machine without this system-wide stutter.

A signed official MSIX for 26.803.10989.0 was installed as a reversible A/B baseline on 2026-08-16. Package install completed successfully; extended idle CPU sampling on that baseline is the next planned test.

This evidence does not establish a single root cause, but it rules out a corrupt local installation and shows that minimization alone does not stop the CPU loop. Please prioritize investigation of Windows desktop main/renderer background work that survives an idle state or a minimized window.

stephen-drew · 11 days ago

Same regression here, with measurements, on 26.810.7004.0 (OpenAI.Codex MSIX package), Windows 11 build 26100.9168.

Hardware: Intel i7-7700K (4 cores / 8 threads), 64 GB RAM, NVIDIA GTX 1080 Ti, single 3440x1440 display.

Symptom: identical to the report above. System-wide cursor stutter and typing lag whenever the app is running, worst in the seconds right after submitting a prompt. Machine is completely normal the moment the app is fully quit, and stutters again immediately on relaunch. Clean Windows reboot does not help.

Measured while the app was running (performance counters, 1-second samples):

  • Interrupts/sec: 17,000 to 25,000 with the app idle, 42,000 to 80,000 during active turns, evenly spread across all 8 logical processors. A normal desktop baseline is roughly 2,000 to 5,000. After quitting the app the rate returns to normal.
  • Context switches/sec: average 36,600, peak 66,000 during an active turn.
  • System timer resolution: pinned at 1.00 ms (NtQueryTimerResolution current = 10000) the whole time the app runs, versus the 15.625 ms default.
  • Main codex.exe process: about 203 threads and 2 GB working set within two minutes of launch.
  • Processor queue length spikes of 10 to 14 during turns despite CPU utilisation staying low (Codex around 1 to 3 percent of machine CPU), which matches the felt experience: the machine looks idle but input stutters.
  • WmiPrvSE CPU: 0 percent throughout, so this is not the WMI snapshot variant described in issue 36025 and related reports. DPC time was about 0.9 percent, so driver-side DPC flooding is not evident either. The load shows up as raw interrupt and context-switch churn.
  • Possibly related: during busy turns, launching an elevated process from the app's own shell sessions failed with 0xc0000142 (process initialisation failure), which suggests the session is under resource pressure while the app is active.

Repro is trivial: app running equals stutter, app quit equals perfectly smooth. One hundred percent reproducible across reboots on this machine.

shleder · 11 days ago

The 27+ GB / 889-rollout local state in this report is a useful scalability/control case for codex-rescue. It does not address the Windows idle-CPU loop itself; I’m field-testing whether session discovery and diagnosis remain bounded and avoid false corruption findings on a very large Codex home.

If you still have that state locally, could you try only the read-only path first?

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

I’m interested in runtime, exit code, discovery result, and the sanitized doctor finding. A healthy result is valid evidence here too.

Please don’t post raw rollouts/SQLite, prompts, credentials, or unredacted paths. Repo: https://github.com/shleder/codex-rescue

manucuervodj · 9 days ago

I’m currently testing Codex App version 26.814.41407. So far, the idle CPU/stuttering issue appears to be resolved on my machine, but I’m continuing to test before confirming it as fixed.

EDIT: I can confirm that the bug is gone for me. Thank you.

whh110112 · 8 days ago

Reproduction on newer Windows package 26.814.5517.0

I can reproduce the same system-wide pointer stutter/jumping and delayed keyboard input on a package newer than the builds discussed above. The symptom is strongest immediately after submitting a normal Codex task and while the turn is executing. It began only with recent desktop releases; older releases on the same machine did not show this behavior.

Environment
  • OpenAI.Codex package: 26.814.5517.0
  • Windows 11 Home x64, build 26200
  • Intel Core i7-12700K, 20 logical processors
  • 31.7 GB RAM
  • NVIDIA GeForce RTX 3070 Ti
  • Time zone: Asia/Shanghai
Affected active-turn capture (August 19, 2026)

A privacy-safe three-second sample collected while the user was experiencing task-related input stutter showed:

  • 19 ChatGPT/Codex-related processes
  • approximately 1.72 logical CPU cores aggregate
  • approximately 2.49 GB working set and 2.41 GB private memory
  • hottest ChatGPT.exe renderer: approximately 0.98 CPU core, 1.08 GB working set
  • ChatGPT.exe main process: approximately 0.71 CPU core
  • codex.exe backend: approximately 0.03 CPU core
  • complete process group read-transfer rate: approximately 3.1 MB/s

The hot processes were the Electron main/renderer path, not the agent backend. The low read-transfer rate also does not match the earlier ~1 GB/s Chrome runtime hashing loop reported in #38547.

Quiet comparison on the same installed package (August 20, 2026, 13:38 +08:00)

A later three-second sample when the severe symptom was not present showed:

  • 23 related processes
  • approximately 0.15 logical CPU core aggregate
  • approximately 1.82 GB working set
  • approximately 0.6 MB/s aggregate read-transfer rate

This appears to be an intermittent bad runtime/UI state rather than fixed baseline resource pressure.

Local-state scale (metadata only)
  • 23 session JSONL files
  • approximately 561.7 MB total
  • largest session: approximately 177.8 MB
  • 8 session files larger than 10 MB
  • local logs_2.sqlite: approximately 176.6 MB in the earlier inspection

This overlaps strongly with #33786 and #20864, especially the completed-thread/full-history hydration path. The largest local session is close to the ~167 MB thread size reported in #33786. No session contents, paths, prompts, account data, task IDs, or raw logs were collected or shared.

Reproduction
  1. Launch Codex Desktop on Windows.
  2. Open an existing local project/thread.
  3. Submit a normal task that begins local tool execution.
  4. While the turn is active, move the pointer and type in Codex or another application.
  5. Observe pointer pauses/jumps and delayed/uneven typing across Windows.
  6. Fully exit/restart Codex; responsiveness improves temporarily.

Please investigate whether the 26.814 Windows renderer/main-process path can still enter a busy state during turn updates or history hydration, despite the earlier 26.810.7004 fix. A privacy-safe diagnostic export identifying renderer window role (main thread vs hidden avatar/PiP/history renderer) would help distinguish the remaining paths.