[Windows] ChatGPT/Codex desktop app causes system-wide mouse stutter when running without elevation

What version of the Codex App are you using (From “About Codex” dialog)?

26.810.41047

What subscription do you have?

plus

What platform is your computer?

No response

What issue are you seeing?

The ChatGPT/Codex Windows desktop app causes severe system-wide mouse cursor stuttering whenever it is running with normal user privileges.
The issue occurs across the desktop, File Explorer, Windows Settings, Notepad, and other applications. Completely exiting ChatGPT immediately restores normal mouse movement.
Interestingly, elevated applications are unaffected while focused. Task Manager, Event Viewer, and Notepad launched as Administrator all have smooth mouse movement.
If ChatGPT itself is launched as Administrator, the stuttering disappears completely system-wide.
This issue is reproducible on two separate Windows PCs.

What steps can reproduce the bug?

Launch the ChatGPT Windows desktop app normally.
Move the mouse over the desktop, File Explorer, Settings, or a normally launched Notepad window. Mouse movement becomes noticeably stuttery.
Launch Notepad as Administrator and focus its window. Mouse movement immediately becomes smooth.
Return focus to a normal application. The stuttering immediately returns.
Completely exit ChatGPT. Mouse movement becomes smooth everywhere.
Alternatively, launch ChatGPT itself as Administrator. The stuttering no longer occurs in any application.
Additional troubleshooting already tested without improvement:
Windows Efficiency Mode
Lowering ChatGPT process priority
Resetting the graphics driver with Win+Ctrl+Shift+B
WMI Provider Host activity appears normal
Codex desktop pet is disabled
CPU utilization is not saturated.

What is the expected behavior?

No response

Additional information

No response

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

[Windows 10 / 26.803] Codex Micro service causes Logitech wireless mouse stutter; full no-device service stub resolves it #37658

Powered by Codex Action

I can confirm a very similar issue and have some additional diagnostic evidence.

Environment

Codex Windows package: OpenAI.Codex 26.810.4967.0
Windows 11 Pro, build 26100
NVIDIA RTX 5080
Display: 2560×1440 at 143 Hz
Mouse: wired Logitech G502 HERO

Integrity-level behavior

The behavior consistently followed the integrity level of the foreground window:

Normal Notepad, Edge, Steam, and non-elevated PowerShell: mouse stuttered.
Task Manager, elevated Notepad, and elevated PowerShell: mouse was smooth.
The mouse remained smooth when an elevated PowerShell window was focused even while the pointer was moved outside that window over the desktop.
The Ctrl+Alt+Del secure desktop was also smooth.
Returning focus to a normal application immediately made the stutter visible again.

This appears consistent with something in the affected user session's normal-integrity input path. That is only an inference, not a confirmed hook implementation.

User-session A/B test

I kept the affected account logged in, created a fresh local standard user, and switched to it without rebooting:

Original user session: stuttered.
Fresh user session on the same machine: completely smooth.

This substantially reduces the likelihood of a physical mouse, USB controller, display driver, or system-wide DWM problem.

Recovery result and `node_repl` observation

During the affected state, the original session had approximately 20 node_repl.exe processes from the Codex computer-use runtime, in addition to the normal Codex/ChatGPT process tree.

Completely terminating:

ChatGPT.exe
codex.exe
codex-code-mode-host.exe
extension-host.exe
node_repl.exe

immediately restored smooth mouse movement.

After relaunching Codex:

only approximately 2 node_repl.exe processes were present;
the mouse remained smooth even while Codex was running.

Therefore, Codex merely being open is not sufficient to reproduce it on this machine. The issue may require a stale or accumulated helper-process state. The node_repl correlation is strong, but I have not yet proven which individual process owns the problematic input path.

If it recurs, I plan to terminate only the accumulated/orphaned node_repl.exe processes first, before restarting the full app, to establish a narrower A/B result.

ETW evidence

I captured a 48-second WPR/xperf trace during the affected state with no lost events. The trace included alternating foreground intervals between:

elevated conhost.exe, where movement was smooth;
normal Steam and Edge windows, where movement stuttered.

Win32k emitted repeated InputProcessDelay events for the Explorer input thread, including delays in roughly the 78–234 ms range for mouse-related messages such as WM_MOUSEMOVE (MessageId 512) targeting Shell_TrayWnd / SystemUserAdapterWindowClass.

There was no corresponding sustained CPU, disk, DPC, or interrupt saturation that explained the visible cursor stutter.

I also captured an additional loader trace, but it ultimately ruled out the initially suspected Explorer extensions.

The ETL files are not attached publicly because they contain local paths and process metadata, but I can provide sanitized summaries or traces privately if a maintainer requests them.

Restarting Explorer alone did not resolve it.

The strongest current lead is an abnormal accumulated Codex helper-process state, particularly the unusually large number of computer-use node_repl.exe instances.

I can reproduce this on the same ChatGPT Desktop build, with the agent-task trigger and process-level observations below.

Environment

Windows 11 x64
ChatGPT Desktop: 26.810.41047
Powered by Codex & OWL
CPU: Intel Core i7-10750H (6C/12T)
RAM: 32 GB
GPU: Intel UHD Graphics + NVIDIA GTX 1650 Ti

Trigger and resource usage

The stuttering occurs while a ChatGPT/Codex agent task is running. It affects mouse/input across the entire Windows desktop, not only the ChatGPT window.

During the affected state:

Main ChatGPT process: approximately 9–12% CPU
codex.exe: close to 0% CPU
GPU: close to 0%
Disk usage: very low
Memory usage: normal
Minimizing ChatGPT does not improve the stuttering

Elevation/integrity-level A/B result

With ChatGPT running normally (non-elevated):

ChatGPT, Chrome, Explorer, and normal CMD foreground: severe stuttering
Elevated CMD (Run as administrator) foreground: no stuttering
Task Manager foreground: no stuttering

I then completely exited ChatGPT and launched ChatGPT itself using Run as administrator. With ChatGPT elevated, normal CMD, Chrome, Explorer, and ChatGPT all remained smooth while running the same type of agent task.

Running ChatGPT elevated therefore eliminates the system-wide input stuttering completely on this machine. This further supports a possible Windows integrity-level/UIPI, input/window hook, accessibility/UI automation, hotkey handling, or OWL/background-component interaction.

Expected behavior

ChatGPT/Codex agent tasks should not cause system-wide mouse/input stuttering when ChatGPT runs with normal user privileges.

Temporary workaround and security concern

Running ChatGPT Desktop as Administrator eliminates the issue, but this is not a suitable permanent workaround because shell commands and child processes launched by Codex may inherit elevated privileges.

Additional observations from a later recurrence on the same machine (OpenAI.Codex 26.810.4967.0):

Time-dependent onset

The onset appears strongly correlated with how long the desktop app has been running.

Immediately after a fresh launch, the issue is usually absent and is very difficult to trigger regardless of normal interaction.
It tends to appear only after the app has remained running for some time.
Codex does not necessarily need to be actively used or in the foreground when the affected state develops.

This suggests that a long-lived or accumulated runtime state may be relevant, although the required elapsed time and exact trigger are not yet known.

Wheel-beep behavior

During the affected state, rapid wheel scrolling produces repeated system-like beeps across normal-integrity targets, including Codex, Chrome, File Explorer, and the desktop.

The beeps disappear together with the pointer stutter when an elevated PowerShell window or the UAC secure desktop is active.
Rapidly moving the pointer while rapidly scrolling makes the beeps disappear or become much less frequent.
Normal video playback and system animations remain smooth.

The beep source has not been identified; it appears coupled to the same input-path failure rather than being an application-specific sound.

Main-process suspend/resume A/B result

I suspended only the main ChatGPT.exe process for 30 seconds while leaving the rest of the process tree running.

Input initially became extremely laggy.
After a short delay, mouse movement became completely smooth and rapid wheel scrolling stopped producing beeps while the process was still suspended.
Immediately after resuming the same process, the global stutter and wheel beeps returned.

This establishes a strong causal dependency on the desktop main process. It is behaviorally consistent with a delayed or blocked input callback timing out, but it does not prove a specific hook API.

Resetting the persistent browser-control runtime and separately stopping extension-host.exe and the diagnostic/browser app-server did not change the symptom.

`node_repl.exe` count on this recurrence

This recurrence occurred with only 3 node_repl.exe processes present, not approximately 20. Therefore, a large accumulation of node_repl.exe helpers may be one possible trigger or correlated state, but it does not appear to be required for the issue to occur.

During the affected state, the main desktop process sustained approximately 1.18-1.66 CPU-seconds per second, with one thread repeatedly consuming about 68-78% of one logical core. Total system CPU, DPC, and interrupt load were not saturated.

Possible keyboard relationship

Before noticing the global mouse symptom, keyboard input in the Codex composer had intermittently felt delayed or uneven. This was difficult to isolate at the time. Given the later system-wide mouse behavior, the earlier keyboard latency may share the same underlying input-path problem, but this is currently only a correlation and has not been proven.

A longer WPR trace with no lost events is available locally, but I am not attaching it publicly because it contains local paths, process/window metadata, and stacks. Since a focused 48-second trace has already been described above, I will avoid creating or uploading a redundant trace unless a maintainer requests specific providers or a particular reproduction protocol.

I have an additional process-level A/B result that may help narrow this down.

During another occurrence of the stuttering, I observed approximately 20 node_repl.exe processes.

I first terminated all node_repl.exe processes only, while leaving ChatGPT/Codex running.

Result: the system-wide mouse stuttering continued unchanged.

I then terminated only codex.exe.

Result: the mouse stuttering disappeared immediately. The ChatGPT app itself remained open but displayed an error because the Codex process had been terminated.

After restarting ChatGPT normally (non-elevated), mouse movement remained smooth.

So, at least on my system, accumulated node_repl.exe processes do not appear to be sufficient to maintain the stuttering. The affected state appears to depend more directly on codex.exe or runtime state associated with it.

One additional note about the trigger: on this PC, this occurrence appeared after running several Codex tasks. However, on my other PC I have also reproduced the issue immediately after launching ChatGPT without running a Codex task. Therefore, running tasks does not appear to be a required trigger.

What version of the Codex App are you using (From “About Codex” dialog)?

26.810.41047

What subscription do you have?

plus

What platform is your computer?

No response

What issue are you seeing?

The ChatGPT/Codex Windows desktop app causes severe system-wide mouse cursor stuttering whenever it is running with normal user privileges. The issue occurs across the desktop, File Explorer, Windows Settings, Notepad, and other applications. Completely exiting ChatGPT immediately restores normal mouse movement. Interestingly, elevated applications are unaffected while focused. Task Manager, Event Viewer, and Notepad launched as Administrator all have smooth mouse movement. If ChatGPT itself is launched as Administrator, the stuttering disappears completely system-wide. This issue is reproducible on two separate Windows PCs.

What steps can reproduce the bug?

Launch the ChatGPT Windows desktop app normally. Move the mouse over the desktop, File Explorer, Settings, or a normally launched Notepad window. Mouse movement becomes noticeably stuttery. Launch Notepad as Administrator and focus its window. Mouse movement immediately becomes smooth. Return focus to a normal application. The stuttering immediately returns. Completely exit ChatGPT. Mouse movement becomes smooth everywhere. Alternatively, launch ChatGPT itself as Administrator. The stuttering no longer occurs in any application. Additional troubleshooting already tested without improvement: Windows Efficiency Mode Lowering ChatGPT process priority Resetting the graphics driver with Win+Ctrl+Shift+B WMI Provider Host activity appears normal Codex desktop pet is disabled CPU utilization is not saturated.

What is the expected behavior?

No response

Additional information

No response

Same issue here... Please fix this.

Same Issue

Same hard issue. I thought my PC got hacked...

I can confirm this issue with additional controlled measurements.

Environment

Codex/ChatGPT Desktop: 26.810.41047
Windows 11, build 26200
The issue began after the August 15, 2026 desktop app update.

Reproduction and recovery

Immediately after a reboot or fresh app launch, mouse movement can be smooth.
After Codex has been open/running for some time, the physical mouse begins to stutter across the normal Windows desktop.
Completely exiting Codex/ChatGPT immediately restores smooth pointer movement.
On the UAC secure desktop and the Ctrl+Alt+Delete secure desktop, both mouse movement and keyboard navigation are completely smooth.
A Bluetooth keyboard and a separate USB keyboard both show uneven input inside the Codex composer, while typing remains smooth in Notepad, browsers, and other applications.

Objective pointer-timing measurement

Physical cursor-position changes were sampled for 12 seconds in both states.

Affected state:

169 movement updates
average interval: 70.88 ms
median: 16 ms
P90: 247.84 ms
P95: 324.23 ms
P99: 338.29 ms
maximum: 342.74 ms
59 gaps above 20 ms
49 gaps above 40 ms

Smooth state immediately after restart:

776 movement updates
average interval: 15.46 ms
median: 15.23 ms
P90: 16.09 ms
P95: 16.14 ms
P99: 16.21 ms
maximum: 16.56 ms
zero gaps above 20 ms

Programmatic pointer movement using SetCursorPos remained visually smooth during the affected state. This suggests that display/GPU/cursor rendering remained responsive while physical-input delivery was delayed.

Additional eliminations

The same physical mouse works smoothly on another PC.
A separate USB keyboard reproduces the Codex-composer input problem.
Aggregate CPU, GPU, memory, disk, DPC, and interrupt usage did not show saturation.

No raw logs, local paths, account information, or trace files are included in this public comment.

I can reproduce the same input-stutter issue on a newer 26.810 Windows build, with controlled measurements.

Environment

Codex Windows package: OpenAI.Codex 26.810.6296.0
Bundled Chromium: 151.0.7922.137
Windows 11, build 26200
20 logical processors, 32 GB RAM, NVIDIA RTX 4070
Dual-display configuration: 1440p at 165 Hz plus 1080p

Reproduction

The issue began immediately after the desktop app update.
While Codex is the focused foreground window, physical mouse movement and typing hitch at a regular interval of approximately one second.
Subjective severity is 4.5-5 out of 5.
Focusing another application appears to stop the symptom; completely exiting Codex stops it.

Controlled measurements

Across baseline and repeat 20-second samples with Codex focused:

All Codex processes used approximately 7.8-8.0% of the full 20-thread CPU.
The main ChatGPT.exe browser process used approximately 130-133% of one logical core.
The codex.exe backend used approximately 0-0.2% of one logical core.
Disk queue, available RAM, DPC time, interrupt time, and GPU temperature showed no resource saturation.
Current-build app logs contained main_thread_jank_snapshot events substantially more frequently per unit of session time than older-build sessions on the same machine.

Pausing Wallpaper Engine reduced total GPU utilization but did not reduce the abnormal main-browser CPU usage or visible stutter. Exiting NZXT CAM also did not produce a repeatable improvement.

Confounded sample excluded

One apparently improved sample was invalidated because Windows temporarily lost a physical monitor and rebuilt the display topology during that sample. The lower counters coincided with the display-loss interval and are not being attributed to either background application. Separate same-day display-stack instability was observed, so this report does not claim that Codex caused that monitor event.

No raw logs, local paths, account identifiers, hostnames, access information, feedback or session IDs, or conversation content are included in this comment.

Important

Correction to my earlier version of this comment: the initial NVIDIA App / ShadowPlay attribution was confounded by an app restart and timing. A later clean recurrence happened while NvContainerLocalSystem was still Stopped and Disabled. Please disregard the previous recommendation to disable that service as the primary workaround.

Corrected conclusion

The directly reproducible trigger is the lifecycle/state of Codex Desktop's hidden Pet / avatarOverlay window.

When the bug is active, the Pet is not visible, but the hidden avatarOverlay renderer remains alive and continues receiving mirrored global conversation, turn, reasoning-summary, browser-session, and connection events. It also repeatedly reports routing/state errors. Opening the Pet once and then closing it resets/tears down that overlay event path, and system-wide mouse movement becomes smooth immediately without restarting the app.

The exact Windows API responsible for the system-wide input delay is not proven from public/runtime evidence. The strongest boundary is an input/window hook or synchronous callback state associated with the Pet overlay lifecycle. It would be incorrect to claim a specific hook such as WH_MOUSE_LL without an internal stack or source confirmation.

Environment

Windows 11 Pro x64, build 26200
Microsoft Store package: OpenAI.Codex 26.810.6296.0
Packaged ChatGPT.exe / Chromium file version: 151.0.7922.137
NVIDIA GeForce RTX 4060 Ti, driver 32.0.16.1074
Display: 2560x1440 at 200 Hz

Reproduction

Launch ChatGPT/Codex Desktop normally.
Leave it running and use tasks/conversations normally. The Pet itself does not need to be visibly open.
After some time, mouse movement becomes severely choppy across the normal Windows desktop and other applications.
Do not restart the app.
Open the Pet/avatar overlay once and wait until it is visible.
Close the Pet/avatar overlay.
Mouse movement becomes smooth immediately.

The issue can recur after a fresh app launch or after the app has remained running for some time.

Same-process A/B evidence

This is the cleanest result because no process, driver, service, or privilege level changed:

ChatGPT main PID remained 29644 throughout; there was no app restart.
NvContainerLocalSystem remained Stopped and Disabled throughout.
NVDisplay.ContainerLocalSystem remained running.
Before the Pet toggle, the hidden renderer continuously logged events with:

rendererWindowAppearance=avatarOverlay
rendererWindowVisible=false
rendererWebContentsId=3

The hidden renderer received reasoning-summary and turn events for many conversations even though it was not visible, plus repeated errors such as:

Received turn/started for unknown conversation
Received item/completed for unknown conversation
No turns for conversation
Conversation state not found

When the Pet was opened, the same overlay changed to rendererWindowVisible=true.
The final avatarOverlay event was recorded at 2026-08-15T13:13:20.681Z.
After the Pet was closed, there were no further avatarOverlay events for more than three minutes, while the primary window continued receiving heavy live task/event traffic.
Mouse movement became smooth at the same transition, and the user confirmed the recovery.

This establishes a much narrower causal relationship than the earlier service test: closing the Pet stops the stale hidden-overlay event path and clears the input symptom in the same app process.

What the later test ruled out

NVIDIA service is not the direct root cause

The stutter recurred while NvContainerLocalSystem was still disabled and no nvcontainer.exe, NVIDIA Overlay.exe, or NVIDIA Share.exe process existed. Therefore disabling the NVIDIA service does not prevent this bug and should not be presented as the primary fix.

nvspcap64.dll was still resident in some already-running ChatGPT child processes, but the Pet open/close action fixed the mouse without changing that module state. Module presence alone is therefore not sufficient to explain the symptom.

High ChatGPT CPU / process-I/O counters are not sufficient to cause the mouse stutter

During the affected state, the main process used roughly 90-132% of one logical CPU and the renderer/GPU processes were also active. After the Pet was opened and closed and the mouse became smooth, a fresh sample still showed:

main-process CPU average about 145% of one logical CPU
the same high process read-throughput counter (about 756 MiB/s average in that sample)
active renderer/GPU work

Those counters may represent a separate performance regression, but they persisted after mouse responsiveness recovered and therefore are not the direct cause of this cursor symptom.

DPC/interrupt saturation is not required

In the later recurrence, DPC and interrupt time were approximately 0-1% during several windows while the mouse was visibly stuttering. Earlier high DPC observations were therefore not a necessary condition for this bug.

Chromium VideoCaptureService is not the direct CPU hotspot

A video_capture.mojom.VideoCaptureService child process existed, but its measured CPU usage was 0.00 during the affected windows. It is not the current user-mode hotspot, and killing or disabling unrelated capture services is not required for the Pet workaround.

Reliable temporary workaround

When the pointer begins stuttering:

Open the Codex/ChatGPT Pet / avatar overlay.
Wait until the Pet is visibly displayed.
Close or disable the Pet again.

Mouse movement should recover immediately without restarting ChatGPT/Codex and without running the app as Administrator.

If the Pet control cannot be reached, fully quitting and relaunching the app may also reset the state temporarily, but opening and closing the Pet is the more targeted workaround.

Running the whole app as Administrator is not recommended because agent-launched commands and child processes may inherit elevation.

Suggested product fix

Please audit the avatarOverlay lifecycle and event routing:

Do not create or subscribe the hidden overlay to global AppServer/conversation/turn/reasoning broadcasts until the user explicitly opens Pet.
When Pet is closed, destroy its BrowserWindow/webContents or fully detach all event listeners, IPC routes, input hooks, hotkeys, and window callbacks.
Ensure a hidden/closed avatarOverlay cannot continue receiving events for unrelated conversations.
If a global mouse/input hook is used, guarantee bounded callback time and remove it when Pet is closed.
Add a Windows regression test: with Pet closed, the overlay must receive no global task events; opening and closing Pet repeatedly must be idempotent and must not leave input registrations behind.

Related Pet/avatar reports: #38745 and #38663.

Same issue here, with measurements that narrow it to a single process.

Environment

Windows 11 Pro 26200, 32 logical cores
App: OpenAI.Codex 26.810.4967.0 (Microsoft Store MSIX), Chromium 151.0.7922.137
Mouse: Logitech MX Anywhere 3S over Bluetooth LE, native report rate ~133 Hz

It is the main browser process, not the GPU process

I suspended every thread of the app (968 threads across 27 processes), measured, resumed, then repeated while suspending only individual PIDs. Suspending the single main browser process (the ChatGPT.exe with no --type= flag) produces the identical fix to suspending all 27:

state	moving events / 20s	stalls >33ms	per 100 events
app running (~76 min uptime)	1395	89	6.4
all 27 processes suspended	2185	3	0.1
only main browser process suspended	1218	3	0.2
app fully quit	792	0	0.0
freshly launched app (1 min uptime)	2617	0	0.0

Cursor event rate roughly triples with the app frozen, 38/sec vs 109/sec, with identical mouse motion. p90 inter-event gap goes from 22.90 ms to 7.70 ms. Worst single stall goes from 287 ms to 15 ms.

Not a resource contention problem

Measured while the stutter was active: the app used 2.2 of 32 cores (~7% of the machine), GPU utilization 1.3%, 25 GB RAM free. Freezing threads on a machine that idle does not free meaningful capacity. The GPU process is a separate PID from the culprit, which is consistent with graphics driver resets and MPO tweaks not helping.

The stutter also occurs with the app window in the background, unfocused.

Possible mechanism

This is inference, not proof, since Windows exposes no API to enumerate hook owners: the pattern fits a low-level mouse hook (WH_MOUSE_LL) on the main process. Windows serializes every mouse event through every installed LL hook, so one slow hook handler stalls the cursor system-wide regardless of focus. The main process owns a WS_EX_TOPMOST | WS_EX_LAYERED | WS_EX_TRANSPARENT | WS_EX_NOACTIVATE overlay window, which is the kind of feature that needs such a hook. LowLevelHooksTimeout is at the 1000 ms default here.

Possible uptime or workload dependency

A freshly launched app measured perfectly clean (0 stalls in 2617 events), while an app up for ~76 minutes measured 6.4 per 100. Caveat: the fresh instance also had no chats open and 10 processes vs 27, so uptime and workload are confounded in my data and I have not separated them. Worth checking whether the handler degrades over uptime or with open conversations.

The elevation workaround is not available on the Store build

Running the app elevated cannot be done with the MSIX distribution:

Right-click "Run as administrator" on the Store shortcut is a no-op. The shortcut has no TargetPath; it points at the package application ID, and the packaged launch path ignores elevation. Verified the resulting process token: MEDIUM integrity, same as a normal launch.
Launching app\ChatGPT.exe directly from an elevated shell fails with "Windows cannot access the specified device, path or file." C:\Program Files\WindowsApps is TrustedInstaller-owned and blocks traverse, so the path is unreachable even elevated.

Since there is no official non-Store installer (#13993, #21538), Store users have no way to apply the workaround. Current workaround for us is quitting and relaunching the app when the cursor degrades.

Repro / measurement script

Installs its own WH_MOUSE_LL hook and reports the inter-event gap distribution while you move the mouse in circles for 20 seconds. It only counts a gap as a stall if the cursor jumped >=12 px across it, so pauses in motion do not register as stalls. Read-only, removes the hook on exit.

PowerShell probe

param([int]$Seconds = 20, [string]$Label = "run")
$src = @"
using System;using System.Runtime.InteropServices;using System.Collections.Generic;using System.Diagnostics;
public class MouseProbe3 {
  [StructLayout(LayoutKind.Sequential)] public struct MSG { public IntPtr hwnd; public uint message; public IntPtr wParam; public IntPtr lParam; public uint time; public int x; public int y; }
  [StructLayout(LayoutKind.Sequential)] struct MSLL { public int x; public int y; public uint mouseData; public uint flags; public uint time; public IntPtr extra; }
  delegate IntPtr HookProc(int nCode, IntPtr wParam, IntPtr lParam);
  [DllImport("user32.dll", SetLastError=true)] static extern IntPtr SetWindowsHookExW(int idHook, HookProc lpfn, IntPtr hMod, uint dwThreadId);
  [DllImport("user32.dll")] static extern bool UnhookWindowsHookEx(IntPtr hhk);
  [DllImport("user32.dll")] static extern IntPtr CallNextHookEx(IntPtr hhk, int nCode, IntPtr wParam, IntPtr lParam);
  [DllImport("kernel32.dll")] static extern IntPtr GetModuleHandleW(string name);
  [DllImport("user32.dll")] static extern int GetMessageW(out MSG m, IntPtr h, uint a, uint b);
  [DllImport("user32.dll")] static extern bool TranslateMessage(ref MSG m);
  [DllImport("user32.dll")] static extern IntPtr DispatchMessageW(ref MSG m);
  [DllImport("user32.dll")] static extern IntPtr SetTimer(IntPtr h, IntPtr id, uint ms, IntPtr proc);
  [DllImport("user32.dll")] static extern bool KillTimer(IntPtr h, IntPtr id);
  [DllImport("winmm.dll")] static extern uint timeBeginPeriod(uint p);
  [DllImport("winmm.dll")] static extern uint timeEndPeriod(uint p);
  static IntPtr hook; static HookProc proc;
  public static List<double> gaps = new List<double>();
  public static List<double> jumps = new List<double>();
  static Stopwatch sw = new Stopwatch(); static double last = -1; static int lx, ly; static bool have;
  static IntPtr Cb(int nCode, IntPtr w, IntPtr l) {
    if (nCode >= 0 && (uint)w == 0x0200) {
      double t = sw.Elapsed.TotalMilliseconds;
      var p = (MSLL)Marshal.PtrToStructure(l, typeof(MSLL));
      if (last >= 0 && have) {
        gaps.Add(t - last);
        double dx = p.x - lx, dy = p.y - ly;
        jumps.Add(Math.Sqrt(dx*dx + dy*dy));
      }
      last = t; lx = p.x; ly = p.y; have = true;
    }
    return CallNextHookEx(hook, nCode, w, l);
  }
  public static void Run(int seconds) {
    timeBeginPeriod(1); sw.Start(); proc = Cb;
    hook = SetWindowsHookExW(14, proc, GetModuleHandleW(null), 0);
    if (hook == IntPtr.Zero) throw new Exception("SetWindowsHookEx failed: " + Marshal.GetLastWin32Error());
    SetTimer(IntPtr.Zero, (IntPtr)1, 100, IntPtr.Zero);
    MSG m;
    while (sw.Elapsed.TotalSeconds < seconds) {
      if (GetMessageW(out m, IntPtr.Zero, 0, 0) == 0) break;
      TranslateMessage(ref m); DispatchMessageW(ref m);
    }
    KillTimer(IntPtr.Zero, (IntPtr)1); UnhookWindowsHookEx(hook); timeEndPeriod(1);
  }
}
"@
Add-Type -TypeDefinition $src -Language CSharp
[MouseProbe3]::Run($Seconds)
$g = [MouseProbe3]::gaps; $j = [MouseProbe3]::jumps
if ($g.Count -lt 100) { "LABEL=$Label SAMPLES=$($g.Count) -- too few, mouse not moved enough"; exit 1 }
$stalls = @(); for ($i=0; $i -lt $g.Count; $i++){ if ($j[$i] -ge 12) { $stalls += $g[$i] } }
$moving = @(); for ($i=0; $i -lt $g.Count; $i++){ if ($j[$i] -ge 2)  { $moving += $g[$i] } }
$ms = $moving | Sort-Object
function P($a,$p){ $a[[math]::Min($a.Count-1,[int][math]::Floor($a.Count*$p))] }
"LABEL             : $Label"
"moving events     : $($moving.Count)"
"gap_ms  p50       : {0:N2}" -f (P $ms 0.50)
"gap_ms  p90       : {0:N2}" -f (P $ms 0.90)
"gap_ms  p99       : {0:N2}" -f (P $ms 0.99)
"stalls > 33ms     : $((@($stalls | Where-Object {$_ -gt 33})).Count)"
"stalls > 100ms    : $((@($stalls | Where-Object {$_ -gt 100})).Count)"

Note if anyone reuses this: do not use Thread.Sleep in the message pump (it quantizes results to the 15.6 ms system tick and fabricates a ~64 Hz reading), and run each A/B phase in a separate process, since the C# statics persist and the second phase will silently replay the first phase's data.

Additional consolidated observations from my side after reproducing the issue multiple times on two separate Windows PCs.

Reproduction pattern observed

The issue is not triggered by a single universal action, but I have now reproduced one specific trigger path multiple times:

ChatGPT/Codex desktop app is running normally with standard user privileges.
Microsoft Edge is open.
A local web application is running, such as ComfyUI or OpenClaw.
The official ChatGPT browser extension is initially disabled.
After the system/app has been running for some time, enabling the ChatGPT browser extension can cause the system-wide mouse stuttering to begin immediately.

This exact “extension OFF → ON → instant stutter” transition has been reproduced multiple times, including on both of my Windows PCs.

However, the same sequence does not always reproduce immediately after restarting ChatGPT/Codex, which suggests that an additional time-dependent or accumulated runtime state may be required before the browser-extension toggle becomes an effective trigger.

Trigger vs persistent affected state

Once the stuttering has started:

Disabling the ChatGPT browser extension does not restore smooth mouse movement.
Fully closing Edge does not restore it.
Stopping ComfyUI/OpenClaw does not restore it.
Disabling all ChatGPT/Codex plugins does not restore it.
Terminating node_repl.exe processes does not restore it.

This suggests those components may act as triggers or state-transition factors, but they are not required to maintain the affected state after it has been entered.

`codex.exe` behavior

During the affected state:

Suspending the entire codex.exe process does not stop the mouse stuttering.
Terminating only codex.exe immediately restores smooth system-wide mouse movement.

This result has been reproduced on both machines.

Main `ChatGPT.exe` suspend test

I also independently reproduced the main-process suspend behavior previously reported by another user.

During an active stuttering state, I suspended the main parent ChatGPT.exe process.

Observed result:

Immediately after suspension, input became dramatically worse and the mouse was almost unusable.
Within less than approximately 10 seconds, system-wide mouse movement became completely smooth while the main ChatGPT process remained suspended.
The ChatGPT window itself became unresponsive, which is expected while its main process is suspended.
After ending/restarting the app, normal mouse behavior returned.

This appears consistent with a synchronous input callback/hook path initially blocking while waiting on the ChatGPT desktop process, then timing out or becoming detached after the process remains suspended.

Current interpretation

The browser extension appears to be one reproducible trigger path on my systems, but not necessarily the root cause.

The strongest common behavior remains:

The affected state is tied to the ChatGPT/Codex desktop runtime.
Elevated foreground windows are unaffected.
codex.exe termination clears the state immediately.
Suspending the main ChatGPT.exe initially worsens the input stall, but after several seconds the system mouse becomes smooth while the app remains frozen.

This suggests the root issue may involve a process-lifetime-bound input hook/callback or related normal-integrity user-session input path, with multiple different components or UI/runtime states capable of triggering the same underlying failure.

Correction / follow-up: I replaced my earlier NVIDIA/ShadowPlay attribution after a cleaner same-process A/B test.

The stutter recurred while the NVIDIA App service was still stopped and disabled. Without restarting ChatGPT/Codex, opening the Pet once and then closing it immediately restored smooth mouse movement. At the same moment, the hidden avatarOverlay stopped receiving mirrored global task/conversation events; the primary window continued normally.

High ChatGPT CPU/process-I/O counters remained after the mouse was smooth, so they are not sufficient to explain the input symptom either.

Please disregard the earlier NVIDIA-service workaround. The corrected evidence, reproduction steps, workaround, and suggested product fix are in the edited report above:

#38546 (comment)

Reliable workaround confirmed again

The stutter recurred again on the same Windows system. If the Pet is already tucked away, wake/open it first, wait until it is visible, and then choose Tuck Away Pet again. Mouse movement became smooth immediately, without restarting ChatGPT/Codex or changing any process, service, or privilege level.

This wake → tuck away sequence has now worked consistently on every recurrence we tested. It is not a permanent fix—the issue may return later—but it is a fast, targeted workaround that does not require running the app as Administrator or restarting it.

This repeated same-process recovery further reinforces the Pet / avatarOverlay lifecycle boundary. The exact low-level Windows input mechanism remains unconfirmed.

Detailed same-process A/B evidence: #38546 (comment)

@naipi11

Additional reproduction result that appears to connect the browser-extension trigger with the corrected Pet / avatarOverlay finding.

Reproduction

On my home Windows PC, I was able to reproduce the following sequence:

ChatGPT/Codex Desktop was running normally.
Microsoft Edge was open.
The official ChatGPT browser extension was disabled.
After the app/system had been running for some time, I enabled the ChatGPT browser extension.
System-wide mouse stuttering started immediately at the moment the extension was enabled.

While the stuttering was active, I did not restart ChatGPT, terminate codex.exe, close Edge, or change privilege level.

I then tested the Pet workaround:

Opened the Codex Pet / avatar overlay.
Waited until the Pet was visibly displayed.
Mouse stuttering was still present while the Pet was open.
Closed / tucked away the Pet.
System-wide mouse movement became smooth immediately after the Pet was closed.

Result

The complete observed transition was:

Browser extension OFF → ON
→ immediate system-wide mouse stutter
→ open Pet
→ no change
→ close Pet
→ immediate recovery

This independently reproduces the Pet open/close recovery behavior reported by @naipi11.

It also adds a possible reproducible trigger path: on my systems, enabling the official ChatGPT browser extension can transition the desktop app into the affected state, although this does not happen immediately after every fresh app launch and appears to require some additional runtime/precondition.

Therefore I would currently describe the browser extension as a reproducible trigger/state-transition path rather than the root cause.

The fact that recovery occurs specifically when the Pet is closed is consistent with the corrected avatarOverlay lifecycle/event-routing hypothesis: enabling the browser extension may trigger or expose a stale hidden-overlay state, while closing the Pet tears down or resets that state.

The exact Windows input API or hook mechanism is still unproven.

I reproduced this again and captured CPU measurements immediately before and after the Pet workaround.

Environment

ChatGPT/Codex desktop app: 26.810.6296
Windows 11 Pro 25H2: build 26200.8875
Intel i9-13900K, RTX 4090, 32 GB RAM
Single 3840×2160 display at 143 Hz with G-SYNC/VRR

Affected state

While the system-wide cursor stutter was actively occurring:

Main ChatGPT process: PID 3284
Sustained CPU: 125–156% Processor Time (approximately 1.25–1.56 logical cores)
Initial four-second sample: 129.7%
DWM, WMI Provider Host, NVIDIA containers, Parsec, and ComfyUI showed no measurable CPU activity during the same sample
DPC/interrupt load was not elevated

I did not restart or terminate ChatGPT.

Pet reset test

Opened Settings → Pets
Selected Wake Pet
Waited until the Pet was visibly displayed
Selected Tuck Away Pet
The system-wide cursor stutter stopped immediately and completely when the Pet was tucked away

Important result: CPU remained high

After the cursor became smooth, I sampled the same main process again for five seconds:

PID 3284: 131.9% Processor Time
Cursor behavior: completely normal

Therefore, the mouse recovery was not caused by the high-CPU loop ending. The Pet wake/tuck transition corrected the cursor behavior while the main-process CPU defect continued unchanged.

This suggests two related but separable failure states:

A stale or incorrectly hidden Pet/avatar overlay, input-routing, or composition state that causes system-wide cursor stutter.
A persistent main-process CPU loop that survives the Pet reset.

In a previous affected session, the app log showed an avatarOverlay renderer remaining alive while hidden:

rendererWindowVisible=false
documentVisibilityState=visible

That is consistent with a hidden overlay lifecycle problem, although it does not prove the specific Windows input API involved or that the hardware cursor plane was disabled.

The strongest observed transition is:

cursor stuttering + main CPU ~130%
→ wake Pet
→ tuck away Pet
→ cursor immediately smooth + main CPU still ~132%

I can reproduce this on Windows with Codex/ChatGPT build 26.810.7004.0.

Hardware:

Intel i7-14700K
NVIDIA RTX 5070
2560x1440 primary display at 180 Hz, with additional 60 Hz displays

Symptoms:

With ChatGPT/Codex running normally, mouse movement becomes visibly stepped/jittery.
The rest of Windows may appear mostly responsive, but cursor presentation feels like low refresh rate.
Focusing Task Manager immediately makes cursor movement smooth.
Returning focus to the ChatGPT/Codex window makes the stutter return.
Fully closing the ChatGPT/Codex process family restores normal behavior.
The same general behavior also reproduced in the separately installed Codex Beta package.

This is not explained by overall resource exhaustion:

GPU usage was low.
DPC and interrupt time were low.
System queue length was near zero.
During one affected sample, ChatGPT.exe briefly used approximately 89–103% of one CPU core and DWM reached approximately 18% CPU.

Temporary recovery:

Open Settings → Pets.
Wake the Pet and wait for it to become visible.
Immediately use Tuck Away.
Cursor movement returned to normal without restarting the app or Windows.

This workaround appears to reset a stale hidden avatar/overlay or compositor state. I am not claiming the Pet itself is the root cause; the fact that focusing another window and the wake/tuck cycle both restore smooth presentation suggests a foreground-window or DWM/input-composition issue.

Expected behavior:
ChatGPT/Codex should not affect cursor presentation anywhere in Windows based on which window has focus.

Additional investigation would be useful around:

hidden avatarOverlay lifecycle
foreground-window/focus transitions
normal-integrity versus elevated-window composition
Electron/Chromium cursor presentation and DWM interaction
whether the Pet wake/tuck action forces a renderer/compositor reset

Correction: this reproduction is primarily a turn-start / turn-completion freeze, not an elevation-specific A/B result. I have moved the full sanitized diagnostics and ETW summary to the matching report in #24251:

#24251 (comment)

There may still be overlap because system-wide mouse input is affected on the same 26.810 package family, but elevation was not tested as the defining condition in this reproduction.

Adding sanitized diagnostics from duplicate report #38874. This machine reproduces the same system-wide physical mouse stutter on Microsoft Store package 26.810.7004.0.

Additional data from this reproduction:

Windows 10 Pro 22H2, build 19045; Intel i7-12800HX; 15.7 GB RAM; RTX 4070 Laptop GPU; 2560 x 1600 at 165 Hz.
During the affected state, rapid downward scrolling in a browser with a Logitech free-spin wheel produced repeated beeps from the right speaker, synchronized with the input stalls. Rapid upward scrolling did not produce the same behavior, and muting Windows audio stopped the beeps.
A 77.6-second Chromium performance trace contained about 5.94 million events, 101 renderer main-thread animation-jank events, a longest observed stall of about 327 ms, and 64 dropped-frame markers.
One stable-state interval contained 399 consecutive microtasks occupying the renderer main thread for about 295 ms.
Local logs_2.sqlite is about 2.51 GB with 88,599 rows and about 67% free pages. About 748 MB of retained content is transport TRACE messages.

The five-second process sample did not show machine-wide resource saturation. The large retained diagnostic state is evidence, not a claimed root cause.

Raw trace and database files are withheld because they may contain local paths, runtime metadata, URLs, or task content. I can provide targeted sanitized extracts if maintainers specify the providers, fields, and time window needed.

I also encountered this issue today, wasn't sure what was going on so I asked Codex itself to help. After some false starts trying to blame other software, I noticed that sometimes when I focused another app the issue would go away. Eventually I decided to hit the update button since it was there, and as soon as Codex quit the problem vanished. It hasn't come back so far, but it's only been a short time. It's particularly obvious that this was a Codex issue because I had nothing else (other than startup programs) running - no browser, no IDE, I had recently rebooted and the only thing I had opened since was Codex.

Environment

Windows build: 26200.8973
CPU: Intel Core i9-12900K
GPU: NVIDIA GeForce RTX 3090 Ti, driver 610.88
Displays: 3 × 3840×2160 at 144 Hz, plus 1 × 1920×1080 at 60 Hz
Affected Codex package: OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0
Package after updating: OpenAI.Codex_26.810.7004.0_x64__2p2nqsd0c76g0
Executable version after updating: 151.0.7922.137

Observed behavior

The mouse pointer appeared visibly stepped or choppy while Codex was in the foreground.
In some cases, focusing another application made pointer movement smooth.
Returning focus to Codex made it choppy again.
Completely terminating Codex made pointer movement immediately smooth.
Updating and relaunching Codex from .6296 to .7004 cleared the condition, and it did not immediately recur.

The system was not under significant CPU, memory, GPU, or disk pressure while this occurred.

I cannot confirm that this was a raw mouse-input problem. A foreground rendering, frame-presentation, or compositor issue could produce the same visible symptom.

Because other reports reproduce the problem on .7004, the update may have reset the affected application/window state rather than permanently fixing it.

Additional affected Windows user with the same foreground/integrity-level signature.

Observed behavior:

With Codex Desktop running, the physical mouse develops visible system-wide stutter/jank.
Switching focus away from the normal Codex/desktop path can make the pointer smooth again; Task Manager is a particularly clear example.
Returning to normal foreground use makes the stutter return.
Fully exiting Codex removes the symptom.

I am intentionally not claiming a specific build for this reproduction because the exact installed version has not yet been captured. The symptom pattern, however, closely matches this issue.

One important distinction from #38547: OpenAI reported the repeated plugin-runtime hashing loop as addressed in 26.810.7004.0, but this tracker already contains reproductions of system-wide mouse/input stutter on 26.810.7004.0. That suggests the hashing regression and this foreground/input-path regression should be treated as separable failure modes, even if they can compound each other.

For a definitive fix, please investigate the normal-integrity foreground input path independently of total CPU/disk load, especially:

any global/low-level mouse hook, cursor polling, accessibility/UI automation, hotkey, or OWL/native input component owned by the desktop process;
whether such callbacks run on or depend on an Electron/main thread that can stall;
hidden/prewarmed overlay/pet renderers and pointer-synchronization loops when the overlay is inactive;
accumulated helper processes/runtime state that can remain attached after tasks complete;
UIPI/integrity-level differences that explain why Task Manager/elevated foreground windows remain smooth.

Suggested acceptance criteria for the fix:

Codex running non-elevated must not measurably increase system-wide mouse/input delivery latency.
Foregrounding Task Manager/elevated windows vs normal windows must not change cursor smoothness.
The app must remain smooth after long-running/multiple agent tasks, not only immediately after restart/update.
No global input hook/polling path should depend on a busy Electron main thread; if a hook is not strictly required, it should not be installed.
Inactive overlay/helper/runtime components should be suspended or torn down deterministically.

Running Codex as Administrator may mask the issue on some systems, but it should not be considered a permanent workaround because child processes and shell commands may inherit elevation.

Update from the same system reported above:

After updating the Codex/ChatGPT Windows desktop app on August 17, 2026, the system-wide mouse cursor stutter no longer reproduces.

Same PC and input devices
No additional Windows, Bluetooth, mouse, display, or power-setting changes were required
Mouse movement remains smooth while Codex is open and in normal use

This strongly suggests that the regression affecting this environment was resolved by the newer desktop app update. I am leaving the exact fix/build attribution to the maintainers because I have not independently verified which internal component changed.

I also updated but Im still have the stuttering issues

I can reproduce a related issue on Windows with ChatGPT/Codex desktop version 26.814.5167.0.

Environment:

Desktop PC: Intel i9, 128 GB RAM, NVIDIA RTX 3080
Chrome and ChatGPT Work on the web remain smooth
The desktop app UI becomes noticeably choppy while opening Settings, typing, or using Work/Codex, even without a project actively running.

The system is not resource constrained when it happens. CPU/GPU/RAM usage is relatively low, but the ChatGPT/Codex desktop process shows high power usage and the UI stutters.

A workaround that immediately resolved the issue for me:

Open Settings → Pets
Enable/Wake the Pet and wait until it becomes visible
Click Tuck Away

After Wake → Tuck Away, the desktop UI stopped lagging immediately. This strongly suggests an inactive Pet/overlay/compositor state rather than a HID or mouse-driver conflict.

I also uploaded a performance trace from the affected state:
Feedback ID: no-active-thread-01a014c4-0318-7421-a6cb-a76754ec1462

[Windows] ChatGPT/Codex desktop app causes system-wide mouse stutter when running without elevation #38546

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Aug 14, 2026

Phlogist commented on Aug 14, 2026

Environment

Integrity-level behavior

User-session A/B test

Recovery result and node_repl observation

ETW evidence

dmaf87 commented on Aug 14, 2026

Lio-Green commented on Aug 14, 2026

Time-dependent onset

Wheel-beep behavior

Main-process suspend/resume A/B result

node_repl.exe count on this recurrence

Possible keyboard relationship

7C93F3-L commented on Aug 14, 2026

alesmcgregor commented on Aug 14, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Ben2248 commented on Aug 14, 2026

TheZitroX commented on Aug 15, 2026

discovery0418 commented on Aug 15, 2026

Environment

Reproduction and recovery

Objective pointer-timing measurement

Additional eliminations

codexerra commented on Aug 15, 2026

Environment

Reproduction

Controlled measurements

Confounded sample excluded

8 remaining items

naipi11 commented on Aug 15, 2026

Corrected conclusion

Environment

Reproduction

Same-process A/B evidence

What the later test ruled out

NVIDIA service is not the direct root cause

High ChatGPT CPU / process-I/O counters are not sufficient to cause the mouse stutter

DPC/interrupt saturation is not required

Chromium VideoCaptureService is not the direct CPU hotspot

Reliable temporary workaround

Suggested product fix

silverdolphin863 commented on Aug 15, 2026

7C93F3-L commented on Aug 15, 2026

Reproduction pattern observed

Trigger vs persistent affected state

codex.exe behavior

Main ChatGPT.exe suspend test

Current interpretation

naipi11 commented on Aug 15, 2026

naipi11 commented on Aug 15, 2026

Reliable workaround confirmed again

7C93F3-L commented on Aug 15, 2026

Reproduction

Result

Lipton1010 commented on Aug 15, 2026

Environment

Affected state

Pet reset test

Important result: CPU remained high

hawkzlol commented on Aug 16, 2026

ViperTecCorporation commented on Aug 16, 2026

kaki-jiu commented on Aug 16, 2026

zeel01 commented on Aug 16, 2026

Recovery result and `node_repl` observation

`node_repl.exe` count on this recurrence

`codex.exe` behavior

Main `ChatGPT.exe` suspend test