›_ Codex Issues
Codex Issues / #36091

[Windows App] Active Codex turns cause system-wide stutter; stopping `codex-computer-use.exe` eliminates it

Resolved 💬 3 comments Opened Jul 30, 2026 by SlavaVasilakiy Closed Aug 18, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

[Windows App] Active Codex turns cause system-wide stutter; stopping codex-computer-use.exe eliminates it

What version of the Codex App are you using?

  • Codex Windows app: 26.721.4979.0 (Microsoft Store, x64)
  • Bundled Computer Use runtime: @oai/sky 0.5.2

What subscription do you have?

ChatGPT Pro

What platform is your computer?

  • Microsoft Windows 11 Pro Insider Preview
  • Version 10.0.26300, build 26300, x64
  • AMD Ryzen 9 5900X, 12 cores / 24 logical processors
  • 64 GB RAM
  • NVIDIA GeForce RTX 4080 SUPER
  • NVIDIA driver 32.0.16.1074, dated 2026-07-01
  • Display: 2560×1440 at 165 Hz
  • Hardware-accelerated GPU scheduling enabled (HwSchMode=2)

What issue are you seeing?

While a Codex turn is actively running, the entire Windows desktop repeatedly stutters or freezes. Window movement, Start menu interaction, and general desktop input become visibly choppy. The stutter stops immediately when the active Codex turn completes.

This reproduces with both short and long Codex threads. A long-running pursuit goal made the problem last continuously, but a short thread also reproduced it, so thread-history size is not required.

The issue remained after:

  • closing VS Code completely;
  • minimizing Codex to the tray;
  • exiting MyDockFinder;
  • setting Codex and VS Code GPU processes to Normal priority.

A controlled A/B test strongly implicates the bundled Computer Use helper:

| Condition | Result |
| --- | --- |
| codex-computer-use.exe running, Codex turn active | Recurrent system-wide stutter |
| Only codex-computer-use.exe stopped, equivalent 30-second Codex operation active | No stutter observed |

During the second condition, normal agent work continued, codex-computer-use.exe remained stopped, total CPU averaged 5.7%, processor queue length remained 0, and Codex GPU utilization peaked around 1.53%.

This does not prove the exact defect is inside codex-computer-use.exe, but the controlled result makes that process or its UI Automation integration the strongest suspect.

What steps can reproduce the bug?

  1. Launch Codex Desktop on the Windows system described above.
  2. Confirm that codex-computer-use.exe is running from the bundled @oai/sky runtime.
  3. Start any Codex operation that remains active for approximately 30 seconds.
  4. While the turn is running, move windows, open the Start menu, and interact with the desktop.
  5. Observe repeated desktop-wide stutter during the active turn.
  6. Wait for the Codex turn to finish and observe that the stutter stops immediately.
  7. Stop only codex-computer-use.exe.
  8. Repeat an equivalent 30-second Codex operation.
  9. Observe that normal agent work continues and the desktop no longer stutters.

What is the expected behavior?

Normal Codex turns that do not use Computer Use should not cause desktop-wide stutter. The Computer Use helper should remain idle or terminate when it is not needed, and any UI Automation or desktop-discovery work should not interfere with DWM responsiveness.

Additional diagnostic information

Codex feedback session ID: 019fb139-9c31-79d0-9ac1-eb0a5a552501

A 68.115-second Windows Performance Recorder trace was captured while the issue reproduced.

  • dwm.exe used 4.43% of total capacity across 24 logical processors.
  • dwmcore.dll accounted for 3.57% of total CPU capacity.
  • UIAutomationCore.dll activity appeared in both the Codex shell and codex-computer-use.exe.
  • The Codex backend process itself was comparatively lightly loaded.
  • Approximately 47 GB of RAM remained available.
  • Disk queue stayed around 0.00–0.07.
  • No recent display-driver or hardware errors were found in the Windows System event log.
  • The trace did not show a sustained classic DPC/ISR storm: 99.97% of 150,244 DPCs completed within 128 μs. nvlddmkm.sys recorded only two DPCs in the 1024–2048 μs bucket.

A sanitized diagnostic summary can be attached. The raw 1.7 GB ETL is being withheld because it may contain local paths, process metadata, and other private session information. It can be provided through a private, secure upload channel if requested.

Temporary workaround

Stopping codex-computer-use.exe eliminates the stutter in the controlled test while ordinary Codex agent work continues. Computer Use and accessibility-driven desktop control may be unavailable until the Codex app is restarted.

Related but distinct reports

  • Possibly related to #34158, which reports similar system-wide stutter. This report additionally isolates the behavior to codex-computer-use.exe through a controlled A/B test and includes WPR evidence.
  • #33431: same helper process, but reports unbounded private-memory growth rather than active-turn-only stutter.
  • #35538: similar system-wide Windows lag, but does not isolate codex-computer-use.exe.
  • #34292: system-wide stutter isolated to synchronous Codex Micro HID discovery on ARM64, which appears to be a different trigger.

Suggested labels: bug, windows-os, app, computer-use, performance.

CODEX-WINDOWS-STUTTER-DIAGNOSTIC-SUMMARY.txt

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 29 days ago

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

  • #36025

Powered by Codex Action

SlavaVasilakiy · 22 days ago

Correction: extended testing still reproduces the issue on 26.730.8199.0

The earlier no-stutter result came from a short controlled Computer Use test. After leaving the helper resident and allowing agent work to continue for longer, the issue returned. That earlier resolution comment was premature and is being removed.

Extended test setup

  • Codex App: 26.730.8199.0 x64
  • Computer Use was exercised with 45 input actions and 17 UI Automation/window-state captures.
  • codex-computer-use.exe was then left running; it was not terminated during the active/background/idle measurements.
  • Process metrics were sampled once per second using Get-Process, without WMI-based monitoring.
  • Desktop responsiveness was checked by moving windows, opening Start, scrolling, and interacting with other applications.

Results

| Phase | Duration | codex-computer-use.exe CPU | ChatGPT.exe CPU | User-visible result |
| --- | ---: | ---: | ---: | --- |
| Foreground active turn | 56.8 s | 17.61% of one logical processor | 44.02% of one logical processor | Micro-stutter |
| Background agent active | 199.7 s | 18.02% | 74.60% | Stutter became substantially stronger |
| Severe-stutter sample | 15 s | 33.33% | 100% | Freezes approached the original severity |
| Clean idle after all agents completed | 87.6 s | 4.57% (0.19% of total 24-thread capacity) | 25.12% | Micro-stutter remained |

During all measured phases:

  • powershell.exe count remained 0;
  • WmiPrvSE.exe recorded no CPU increase;
  • the old PowerShell/WMI storm was not present;
  • the helper working set increased from approximately 92 MB to 128.5 MB and then remained stable.

Causal A/B test

While micro-stutter was still present in the clean-idle phase, only codex-computer-use.exe PID 35088 was terminated. No other Codex or ChatGPT process was stopped.

Result:

  • all desktop stutter disappeared immediately;
  • the helper did not respawn during the following 60-second observation window;
  • ChatGPT.exe continued using approximately 23.33% of one logical processor;
  • PowerShell and WMI activity remained absent;
  • no stutter was observed during that window.

Updated conclusion

The major PowerShell/WMI storm fixed around #36025 appears to be gone, but a separate Computer Use/UI Automation issue remains. After Computer Use is exercised, codex-computer-use.exe stays resident and continues background activity. Stutter severity appears to increase during long-running or concurrent agent work and persists at a lower level after all agents finish. The exact cumulative mechanism is not yet proven; possible causes include repeated UI Automation subscriptions, queued UIA events, or duplicated event handlers.

This appears closely related to #36833. Please investigate the helper lifecycle and background UI Automation event handling, and keep this issue open.

The workaround remains: terminating only codex-computer-use.exe immediately restores normal desktop responsiveness, while ordinary Codex work continues.

vladon · 11 days ago

Independent reproduction on a newer Windows build (26.810.4967.0)

I can independently reproduce system-wide pointer stutter while a Codex turn is actively thinking or executing ordinary shell/tool work. The stutter affects both an external mouse and the built-in Synaptics touchpad.

Environment

  • Codex Windows package: OpenAI.Codex_26.810.4967.0_x64__2p2nqsd0c76g0
  • Windows 11 x64, build 26200
  • 20 logical processors
  • 64 GB RAM
  • Hybrid graphics:
  • Intel Iris Xe, driver 32.0.101.7085
  • NVIDIA T600 Laptop GPU, driver 32.0.15.9652
  • Active display path observed at 3440×1440, 179 Hz

Reproduction

  1. Restart the Codex app.
  2. Confirm that desktop and pointer movement are smooth.
  3. Start a Codex turn that thinks or executes tools for several seconds.
  4. Move either the external mouse or touchpad while the turn is active.
  5. Observe system-wide pointer/UI stutter.
  6. Restarting Codex restores smooth behavior, but the stutter returns during the next active turn.

No Computer Use actions had been invoked before this reproduction and the ETW capture. The work consisted of ordinary Codex turns and PowerShell diagnostics.

Isolation results

  • Terminating a high-CPU Telegram instance reduced CPU usage but did not change the stutter.
  • Terminating XMouseButtonControl.exe did not change the stutter.
  • Approximately 32 GB RAM remained available; committed memory was ~48%.
  • Disk active time and queue were effectively zero.
  • Overall CPU was typically 16–37%, so the machine was not globally CPU-saturated.
  • DPC/interrupt counters stayed near 0–1%.
  • No recent display-driver or hardware errors were found in the System event log.

22.207-second WPR/ETW capture while reproducing

  • No lost buffers or events.
  • Main ChatGPT.exe process: 21.75 CPU-seconds, equivalent to 97.9% of one logical processor on average.
  • dwm.exe: 7.75 CPU-seconds, equivalent to 34.9% of one logical processor.
  • The system was still 61.83% idle across all 20 logical processors.
  • Windows UI-delay analysis recorded a 203 ms MsgCheck Delay in the foreground ChatGPT.exe render-host window.
  • The trace did not show a classic DPC/ISR storm or driver-delay pattern.

This confirms the active-turn/system-stutter symptom on a substantially newer app build. In this reproduction, the strongest trace signal was the main ChatGPT.exe process and its foreground message pump, and actual Computer Use automation was not required to trigger it.