[Windows] Mouse becomes severely laggy while Codex is thinking

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

• #38962
• #38874
• #39120
• #39292

Powered by Codex Action

Same! I think Codex Devs are using ultra fast PCs so they don't notice these things!

I can reproduce this on a newer Windows build and captured cursor, CPU, GPU, DPC, I/O, and process-tree measurements.

Environment

• Codex Desktop package: OpenAI.Codex 26.818.5229.0 x64 (ChatGPT.exe)
• Windows 10 Pro 64-bit, build 19045
• Intel Core i5-14600KF, 14 cores / 20 logical processors
• 31.85 GB RAM
• NVIDIA GeForce RTX 4060 Ti, driver 32.0.16.1088
• 2560x1440 at 143 Hz
• HID-compliant mouse

Reproduction and cursor evidence

With Codex active and producing thinking/tool/render updates, I continuously moved the cursor in circles.

• 25-second sample: 2,921 cursor-position changes over about 89,935 px
• Median update interval: 8 ms; p95: 15.1 ms; p99: 22 ms
• Five cursor-update gaps were at least 100 ms; maximum gap was 204 ms
• The independent polling loop never stalled: maximum loop gap was 12.8 ms, with zero loop gaps at or above 50 ms

A second 15-second continuous sample recorded four cursor-update gaps at or above 100 ms (maximum 119 ms), while the polling loop maximum remained 10 ms. This confirms intermittent cursor-position stalls while the measuring process itself remains scheduled.

Process measurements

Short 100 ms CPU windows showed bursts in the active Codex processes. Percentages below are relative to one logical CPU, so 572% is about 5.72 logical CPUs:

• Active renderer: peak 572%, average 44.86% over one 10-second sample
• App server: peak 204%, average 12.24%
• Electron main process: peak 80%
• GPU process CPU: peak 69%

In the synchronized cursor/CPU sample, renderer and app-server peaks were 406% and 188%. However, only one of the four 100 ms+ cursor stalls overlapped a substantial app-server burst (125%), and the other three occurred at relatively low measured CPU. CPU bursts therefore appear to be a contributor, but are not proven to be the only cause.

GPU and driver-side counters were low during reproduction:

• Codex process-tree GPU: 1.36% average, 2.58% maximum
• DWM GPU: 0.49% maximum
• DPC: 0%; interrupt time: 1% maximum
• No relevant Display, NVIDIA, WHEA, HID, or USB warning/error events in the preceding 24 hours
• 13.27 GB RAM remained free, commit was 56%, and paging was 0 pages/sec

The largest renderer was already running with Windows PriorityClass=Idle, so lowering renderer priority is not an available workaround.

This does not match the old Chrome cache retry loop

This does not currently reproduce the #38510 cache-loop signature:

• chrome/latest junction target, timestamps, and file ID remained unchanged during a 10-second observation
• Main process read throughput was only 0.027 MB/s
• The active Chrome integration stayed enabled

Additional app-server/helper accumulation observed

The Codex/ChatGPT process tree contained about 206 processes, 16.72 GB private bytes, and 8.76 GB working set. The app server alone held about 5.9 GB private bytes and had 94 direct child roots.

Notable repeated helper groups:

• 23 xcodebuildmcp@latest roots: about 93 processes / 5.48 GB private bytes
• 20 Codex Security MCP roots: about 40 processes / 1.66 GB private bytes
• 4 Firecrawl MCP roots: about 16 processes / 669 MB private bytes

Those helper groups were idle during the focused 15-second CPU sample, so I am not claiming they directly caused each cursor stall. They may still contribute to app-server memory/GC pressure after many tasks are opened. No processes were killed because their exact task ownership is not exposed in the command lines.

The user-visible behavior remains the same as the original report: mouse movement becomes intermittently heavy/floaty while Codex is active, then returns to normal. Please investigate both the foreground renderer/input scheduling path and app-server per-task helper lifecycle/unloading on Windows.

Additional measurements on the affected machine after a full Codex relaunch, current package OpenAI.Codex 26.818.5229.0:

• Relaunch reduced the Codex process tree from 206 processes / 16.72 GB private bytes to 51 processes / 3.51 GB, but the pointer complaint persisted. This argues against accumulated MCP/helper processes as the root cause.
• A separate 550.721-second F: USB-volume monitor recorded 12 samples, 0 MiB used/free delta, and 0 new Disk/UASPStor/exFAT events 51/129/141/153. The external project drive is not supported as the trigger in this occurrence.
• The packaged app still prewarms a hidden 410 x 400 avatarOverlay BrowserWindow while electron-avatar-overlay-open=false.
• However, in a 60-second post-relaunch/post wake->tuck sample, both hidden overlay/surface renderers stayed at 0% CPU. The visible primary renderer averaged 11.2% of one core and peaked at 376.2%; Electron main averaged 7.7% and peaked at 57.9%. Earlier active-turn samples saw the primary renderer at 406-572% and app-server at 188-204%.
• A no-click synthetic cursor loop completed 6,701 position calls in 60 seconds (p99 loop 9 ms, max 17 ms, no gaps >=50 ms). This supports a turn/update-specific rendering burst rather than a continuously broken Windows mouse/DPC path.
• Local thread_history_1.sqlite is 2.19 GB, but 421,776 of 535,875 pages are on the freelist; live item JSON is ~419.6 MiB, of which ~310.7 MiB is image-generation payload. The current thread projection is 390 items / 3.5 MiB. This may be relevant to turn-boundary page-in/projection work, but is not yet causal.

The documented no-restart wake-Pet -> tuck-away cycle was applied successfully. Subjective pointer outcome is pending. An exact-renderer priority experiment was also attempted, but Chromium overwrote that priority on foreground/background transitions, so it is not being claimed as a persistent mitigation. No process was killed and no persistent config was changed. I will report whether the Pet reset actually helps instead of treating the intervention as a fix.