[Windows 11][26.813.12317] ChatGPT/Codex causes persistent system-wide mouse lag and ~10% CPU while idle

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

• #38546
• #38547
• #38551
• #38554
• #38559

Powered by Codex Action

I reviewed the potential duplicates. My report is from 26.813.12317, which is newer than the 26.810.4967 version mentioned in several of these reports. The issue is still reproducible in 26.813.12317.

I’m seeing the same system-wide mouse/input stuttering on ChatGPT Desktop 26.810.41047, specifically while a Codex agent task is running.

I posted detailed reproduction steps and measurements in https://github.com/openai/codex/issues/38546, including this elevation/integrity-level A/B result:

• Normal ChatGPT process: severe system-wide stutter.
• Elevated CMD or Task Manager foreground: no stutter.
• Running ChatGPT itself as Administrator eliminates the stutter system-wide.
• Main ChatGPT process uses approximately 9–12% CPU while codex.exe remains near 0%.

This may be related to the same underlying Windows input/integrity-level issue, with agent-task execution acting as the trigger in my case.

I can reproduce what appears to be the same issue on a slightly different Codex desktop build.

Environment:

• Codex desktop package: 26.810.4967.0
• Executable product version: 151.0.7922.137
• Windows 25H2, build 26200.9168
• 12 logical processors
• Local Windows-native Codex environment
• An in-app browser tab was open during the affected session

Symptoms are essentially the same:

• After the app has been running for some time during a coding session, the Windows mouse pointer begins to stutter and the desktop becomes noticeably less responsive.
• The main ChatGPT.exe process continuously consumes approximately 10–12% CPU even while Codex is idle and waiting for input.
• Fully quitting ChatGPT immediately restores normal mouse responsiveness.
• Restarting the app temporarily resolves the problem, but it returns later.

Measured during one affected state using a five-second CPU sample:

• Main ChatGPT.exe: 11.22% total CPU
• Main process working set: ~0.7–1.0 GB
• Main process private memory: ~1.3 GB
• Codex child processes combined: ~0.03% CPU
• Chrome: ~0.08% CPU

This suggests the sustained load is coming from the desktop UI/renderer process rather than Codex command execution or Chrome.

I also inspected the desktop log from the previous affected run. It contained:

• 610 occurrences of ResizeObserver loop completed with undelivered notifications
• 65 events referring to unknown conversation
• Additional Conversation state not found events

The repeated ResizeObserver errors may indicate a renderer layout/update loop. Events involved both the primary renderer and the hidden avatarOverlay renderer.

This started after the August 14 desktop update and did not occur for me previously.

I can provide a sanitized desktop log if useful.

Mouse Movement Stuttering After Prolonged Use of the Codex Windows Client

After updating the Codex Windows client to version 26.810.4967.0, prolonged use of Codex causes system-wide mouse movement to become noticeably stuttery, jerky, or unsmooth.

The issue is not limited to the Codex window. Mouse movement is also affected in other applications. Fully exiting Codex immediately restores normal mouse movement.

Environment
Operating system: Windows 11, system version approximately 10.0.26100
Codex version: 26.810.4967.0
Codex app-server version: 0.148.0-alpha.9
Browser engine version: Chromium 151.0.7922.137
GPU: AMD Radeon RX 9070 XT
GPU driver: 32.0.22029.9039
Other display devices: AMD integrated graphics, GameViewer Virtual Display Adapter
Time zone: Asia/Hong_Kong
Steps to Reproduce
Launch the Codex Windows client.
Use Codex for an extended period of time, running multiple tasks or keeping long conversations open.
After some time, mouse movement gradually becomes noticeably stuttery.
Close Codex completely. Mouse movement immediately returns to normal.
Restart Codex. The issue may reappear after another period of continued use.

At present, I have not determined the exact amount of time required to trigger the issue, nor whether it is associated with a particular conversation, the Browser feature, or an overlay UI.

Actual Behavior
Mouse movement becomes unsmooth, with noticeable latency, stuttering, or jumping.
Overall CPU and memory usage shown in Task Manager does not appear abnormal.
GPU utilization also does not remain continuously saturated.
The issue disappears immediately after Codex is closed.
No Codex crashes have been observed so far.
Logs and Diagnostic Evidence

The following error repeatedly appears in the Codex logs:

ResizeObserver loop completed with undelivered notifications.

In the current version's logs, this error appears more than 200 times, including periods where it occurs repeatedly at a very high frequency within a short interval.

Log location:

C:\Users\Administrator\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\08\14\codex-desktop-c7775e1a-7476-4774-9e09-139e7f782531-11272-t0-i1-141506-0.log

Example entry from the current log:

2026-08-14T14:15:13.396Z error [electron-message-handler] [desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.

For comparison, only a very small number of similar errors were found in logs from the previous Codex version, 26.803.10989.0. After updating to 26.810.4967.0, the frequency of this error increased substantially.

The current Codex GUI consists of multiple ChatGPT.exe processes, including:

Main process with approximately 1 GB Working Set
GPU process with approximately 676 MB Private Bytes
Multiple renderer processes
An invisible avatarOverlay renderer window

During troubleshooting:

GPU utilization was usually below 1%.
No display driver reset events were found.
No Codex crash events were found.
Memory usage fluctuated significantly over short periods, but no typical memory leak characterized by continuous monotonic growth has been confirmed.
Preliminary Assessment

My current suspicion is that this may be an Electron/Chromium UI rendering or window-compositing issue introduced in version 26.810.4967.0.

The continuously occurring ResizeObserver layout loop may be causing renderer main-thread stalls or instability in desktop compositor frame scheduling, which could manifest as system-wide mouse movement stuttering. The invisible avatarOverlay window and the presence of multiple renderer processes may also be contributing factors.

The following possibilities cannot yet be ruled out:

A long conversation or a particular page state triggering a layout loop;
A window lifecycle issue involving the Browser feature or the avatar overlay;
Compatibility issues between the AMD GPU driver and the newer Electron compositing implementation;
Effects introduced by newer UI features such as concurrent reasoning summaries.
Expected Result

I would appreciate it if you could:

Investigate the significant increase in ResizeObserver errors in version 26.810.4967.0.
Check whether the invisible avatarOverlay window continues to participate in rendering or layout calculations.
Compare renderer, window compositing, and GPU-related changes between versions 26.803.10989.0 and 26.810.4967.0.
Confirm whether this is a known issue and provide any available workaround.
If this is confirmed to be a regression, provide a fix as soon as possible or make a rollback option available.

Temporarily closing and restarting Codex restores normal mouse movement, but this only provides temporary relief.

The same.
ChatGPT Windows desktop app causes persistent high CPU usage and system-wide mouse stutter.

App package version: 26.810.4967.0
Chromium version: 151.0.7922.137
CPU: AMD Ryzen 7 5700X
RAM: 64 GB
GPU: NVIDIA GTX 1060 3 GB

Observed behavior:

• ChatGPT consumes approximately 9–14% total CPU while idle.
• The main ChatGPT process alone consumes approximately 8–12% CPU.
• One main-process thread approaches 100% usage of one logical CPU core.
• Memory fluctuates heavily; approximately 678 MB of private memory and 882 MB of working set were released within one 8-second sample.
• The high CPU usage causes system-wide mouse cursor stutter.
• GPU utilization remains around 1–1.5%.
• Disk queue, DPC time, and interrupt time remain normal.
• Exiting ToDesk and testing in a new blank chat do not resolve the issue.
• Fully quitting and reopening ChatGPT temporarily lowers usage to approximately 1.17%, but the problem returns shortly afterward.
• The issue appeared after the app updated from 26.803.10989.0 to 26.810.4967.0.

The hot path appears to be in the Chromium/V8/Node main event loop, suggesting an event/IPC loop or memory allocation/garbage-collection regression.

Reproduced on Codex 26.810.4967.0, Windows 11, 9900x, 64 GB RAM. Mouse stutters system-wide but remains smooth on the Ctrl+Alt+Delete secure desktop. DPC and interrupt usage are normal. Closing Node processes did not help; fully restarting Codex immediately resolved the stutter.

I ran into this issue as well and investigated it.

It appears that the Windows version of the Codex desktop app (ChatGPT.exe) registers a global low-level mouse hook (WH_MOUSE_LL) on the main thread of the Electron browser process.

This thread is under very heavy load while Codex is executing agent tasks. In my ETW trace, it was the busiest thread on the entire machine, accounting for approximately 13% of all CPU samples.

Because every hardware mouse event must synchronously pass through the WH_MOUSE_LL callback before the cursor position is updated, mouse stuttering occurs system-wide across all applications while Codex is active, regardless of whether the Codex window is in the foreground.

When the mouse is stuttering, if I suspend ChatGPT.exe using Process Explorer, the mouse continues to stutter heavily for about 5 seconds and then becomes smooth again. This ~5-second delay is consistent with the hypothesis that, while the hook remains registered, ChatGPT.exe becomes unresponsive and the system waits for LowLevelHooksTimeout before automatically removing the hook.

As noted in other comments, this issue occurs regardless of whether the machine has ample or limited processing capacity.

A cross-tabulation of per-process CPU samples, including hook-dispatch processing, confirms that the process holding the WH_MOUSE_LL hook is ChatGPT.exe, specifically code within chrome.dll.

During "computer use" sessions, codex-computer-use.exe registers an additional low-level hook for interruption detection. However, the hook on the main thread belonging to ChatGPT.exe itself remains present regardless of whether the "computer use" feature is being used.

This global hook registration is probably unnecessary. Even if it is required, the hook callback should be kept extremely lightweight and any non-trivial processing should be offloaded to a separate thread so that mouse input is never blocked.

I can provide more detailed information, including the ETL trace files, if needed.

I am experiencing the same issue on Windows. After the Codex desktop app has been running for some time, mouse movement across the system becomes noticeably choppy and freezes in short bursts. At that point, total CPU usage is only around 10% and memory usage is around 50%, so the machine is not under heavy resource pressure. Fully closing the Codex app immediately restores smooth mouse movement. This is consistently the quickest way to stop the problem.

Environment

• Codex Microsoft Store package: 26.810.4967.0
• OS: Windows 11 Home x64, version 10.0.26200 (build 26200)
• CPU: AMD Ryzen 7 7840HS with Radeon 780M Graphics, 8 cores / 16 logical processors
• GPU: AMD Radeon 780M Graphics
• GPU driver: 32.0.31035.1003
• Usable RAM reported by Windows: approximately 27.7 GiB

Corroborating report from another affected Windows build, with a decisive app-exit A/B test and local diagnostics.

Environment

• ChatGPT/Codex Microsoft Store package: 26.810.6296.0
• Windows 11 Home x64: 10.0.26200 (build 26200)
• CPU: AMD Ryzen AI MAX+ 395
• GPU: AMD Radeon 8060S, driver 32.0.31035.1003
• RAM: 63.6 GB
• Two 60 Hz monitors

Reproduction and symptoms

1. The problem first appeared shortly after the August 14 desktop-app update.
2. A reboot temporarily cleared it, but it returned when starting/resuming a new app session.
3. Only physical cursor movement stutters system-wide, on both monitors. Typing and other application activity remain responsive.
4. A 2.4 GHz wireless mouse and a separate wired mouse behave identically.
5. Changing USB ports, disconnecting the touch-monitor USB connection, and resetting the graphics driver with Ctrl+Win+Shift+B did not help.
6. Fully quitting ChatGPT/Codex immediately restored perfectly smooth cursor movement. Reopening the app initially clears the condition.

Measurements during the affected state

• Main ChatGPT.exe: about 129% in the Windows per-process performance counter (~1.29 logical CPU cores), 62 threads, and ~1.1 GB working set.
• 12 ChatGPT.exe processes used ~2.7 GB combined.
• Total system CPU remained only ~15–18%; RAM had >40 GB available.
• DPC/interrupt time, disk activity, GPU load, Defender, and WMI activity were low/normal.
• Desktop logs repeatedly showed ResizeObserver loop completed with undelivered notifications, unknown conversation / missing conversation-state errors, and thread/turns/list calls repeating roughly every 3 seconds.
• 26 node_repl.exe helpers had accumulated. Stopping 20 completed helpers did not improve the cursor, and lowering the hot main process to BelowNormal priority also did not help.
• Only terminating the desktop app cleared the lag.

This strongly corroborates the low-level mouse-hook / overloaded Electron main-thread hypothesis described above: mouse movement alone is delayed despite ample RAM and low overall system load. Sanitized log excerpts can be provided if useful.

Independent confirmation: this reproduced on Windows with Codex 26.810.4967.0 earlier today. The system-wide lag coincided with elevated root ChatGPT.exe CPU and process-level I/O while disk, GPU, and memory pressure remained low, closely matching #38547. After the automatic update to .6296 and an app restart, the loop was absent in a short sample; this does not establish that .6296 fixes it.

Independent reproduction with a useful hot-update boundary and post-restart baseline.

Environment

• Windows 11 x64: Microsoft Windows NT 10.0.26200
• Microsoft Store Codex package updated in-place from 26.810.4967.0 to 26.810.6296.0

Timeline (America/Sao_Paulo, 2026-08-14)

• 22:18:39 — 26.810.4967.0 launched and detected the Store update.
• 22:19:22 — old app process exited.
• 22:19:23 — Store install of 26.810.6296.0 completed successfully (HResult 0).
• 22:19:25 — 26.810.6296.0 launched automatically.
• During this first post-update session, physical cursor movement froze and jumped/“teleported” system-wide.
• 22:28:50 — fully closing Codex stopped the symptom immediately.
• 22:29:38 — manually reopening the same 26.810.6296.0 build produced a normal session.

First post-update app-log evidence

The affected session log had 462 lines, including 84 errors:

• 24 item/completed for unknown conversation
• 24 item/started for unknown conversation
• 12 Conversation state not found
• 12 ResizeObserver loop completed with undelivered notifications
• 6 turn/completed for unknown conversation
• 6 turn/started for unknown conversation

The stale-conversation events involved hidden avatarOverlay and quickChat renderers. The ResizeObserver errors burst repeatedly around 22:27:10–22:27:12, and the log also contained main-thread-jank snapshots.

The Computer Use notification configuration reported status=repaired shortly after the new build launched, but no Computer Use action occurred in the affected session. Its driver remained running and idle after Codex was closed while mouse behavior had already returned to normal, so the driver alone was not sufficient to maintain the symptom.

No matching Windows GPU/DWM/HID/USB error events or app crash dump were present.

Post-restart baseline

A passive 15-second WH_MOUSE_LL observation after reopening recorded 2,562 move events, zero LLMHF_INJECTED events, zero lower-integrity injected events, no rapid large jumps, and a maximum adjacent step of 7 px. This was captured after recovery, so it does not identify the affected callback, but it supports the symptom being input latency/stalling rather than synthetic cursor injection.

The hot-update boundary plus hidden-renderer state errors may help narrow the trigger: the bad state appeared only in the automatically launched first session after the update, while a clean launch of the identical build was normal.

https://github.com/openai/codex/issues/38716#issuecomment-5302760473

Temporary no-restart workaround

When the system-wide mouse stutter starts:

1. If the desktop Pet already appears hidden/tucked away, choose Wake Pet (or run /pet).
2. Wait until the Pet is visibly displayed.
3. Choose Tuck Away Pet (or run /pet again).

On another Windows 11 / Codex 26.810.6296.0 system, this restored smooth mouse movement immediately and has worked on every recurrence tested, without restarting Codex or running it as Administrator. Simply leaving the Pet tucked away beforehand was not always enough; the wake → tuck away transition appears to reset the hidden avatarOverlay state.

This is a temporary workaround, not proof that every CPU/I/O regression has the same cause. Detailed same-process evidence: https://github.com/openai/codex/issues/38546#issuecomment-5302228705

Independent Pet-related confirmations: #38663 and #38745.