[Windows][26.810.4967.0] This update makes the entire PC stutter — fully exiting Codex fixes it immediately

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

• #38551
• #38547

Powered by Codex Action

Independent confirmation on Windows 11 build 26200.8875

I can independently reproduce this severe regression in Codex App 26.810.4967.0.

Environment:

• Codex App: 26.810.4967.0, Windows x64 MSIX
• Previous version: 26.803.10989.0
• Update installed: 2026-08-14 at approximately 09:13 MSK
• Windows 11 25H2 x64, build 26200.8875
• Intel Core i7-10700K, 8 cores / 16 logical processors
• NVIDIA GeForce GTX 1660 SUPER, driver 32.0.15.9571
• 48 GB RAM

Symptoms and controlled A/B result:

• After normal use, mouse movement becomes visibly choppy across the entire Windows desktop.
• The lag is not limited to the Codex window and can recur after a Windows restart.
• Fully exiting Codex and terminating the complete ChatGPT.exe process family makes mouse movement smooth immediately, without rebooting or restarting mouse/GPU drivers.

Measurements while stuttering:

• Main Electron ChatGPT.exe process continuously used about 1.1–1.4 logical CPU cores.
• 12-second sample: average 109.5%, maximum 179% (100% = one logical core).
• Independent 10-second CPU-time delta: 14.0 CPU seconds, confirming about 1.4 logical cores.
• Main-process working set grew to about 742 MB.
• Bundled codex.exe, node_repl, and Node task processes were mostly idle.
• No Python process was running.
• About 26 GB RAM remained available; disk queue was zero.
• DPC time was about 0.10%; interrupt time about 0.19%.
• No recent Display/GPU, USB/HID, disk, or WHEA errors were present in Windows event logs.

The recently installed Windows update KB5121003 was also rolled back during troubleshooting, but the Codex-triggered problem still reproduced. This independently confirms the regression on Windows build 26200.8875, not only 26200.9168.

Please provide an urgent hotfix or a supported way to roll back/pin 26.803.10989.0 until fixed.

Additional root-cause isolation from the same Windows build.

Environment

• Windows 11
• Codex Desktop 26.810.4967.0
• Bundled Chrome integration 26.810.41047
• Feedback reference: 01a00072-745f-72a1-83ad-a84c1e1bbd9a

On my machine, the system-wide mouse/keyboard stutter was caused by the installed bundled Chrome integration entering a cache-reconciliation feedback loop.

Procmon evidence over 20.38 seconds

• 51,805 ReadFile operations from the Codex main process
• 51,282 reads were exactly 524,288 bytes
• Approximately 25 GB of logical cached reads
• Codex repeatedly deleted and recreated ~\.codex\plugins\cache\openai-bundled\chrome\latest (about 37 cycles)
• The link target did not change

The installed app code watches the marketplace cache parent for changes and runs Chrome native-host reconciliation. That reconciliation mutates the latest junction, which retriggers the watcher. Runtime synchronization then SHA-256 hashes whole binaries via file reads, producing the sustained CPU/read loop.

Controlled five-second A/B

• Chrome installed and enabled: 6.12 GB logical reads, 6.22 CPU-seconds, 9 junction recreations
• Chrome enabled=false: 6.42 GB, 6.67 CPU-seconds, 8 recreations
• Chrome plugin uninstalled: 0.56 MB, 0.69 CPU-seconds, 0 recreations

The system-wide input stutter stopped immediately when chrome@openai-bundled was uninstalled, without restarting Codex. Disabling it in config was insufficient because the faulty watcher appears to key off installed state rather than enabled state.

No corresponding physical-disk load was observed; the reads were served from cache. The raw Procmon capture was not uploaded because it contains local filesystem/process details.

Independent Windows confirmation, with a potentially different failure mode from the Chrome cache-reconciliation loop described above.

Environment

• Codex Desktop: 26.810.4967.0 (Windows x64 MSIX)
• Windows 11 25H2, build 26220.9022
• ASUS ROG Strix G18 G814JIR
• Intel Core i9-14900HX
• Internal display: 2560x1600 at 240 Hz, driven by Intel UHD Graphics
• Intel GPU driver: 32.0.101.6790 (2025-04-28)
• NVIDIA RTX 4070 Laptop GPU driver: 32.0.16.1088 (2026-07-22)
• Logitech PRO X SUPERLIGHT 2 over LIGHTSPEED, confirmed 1000 Hz report rate

Distinct symptom

The physical/logical mouse input continues to update correctly, but the rendered pointer sprite visibly trails behind the real position. Clicking lands at the intended/current location even when the on-screen pointer image has not caught up.

A direct Win32 probe showed:

• GetCursorPos and GetPhysicalCursorPos returned identical current coordinates
• GetCursorInfo reported the same coordinates
• cursor flags reported visible, not suppressed

This points more toward cursor presentation/composition latency than HID or click/input latency.

Controlled A/B

• Codex open: the pointer-rendering lag can recur across the Windows desktop.
• Fully exit the complete Codex/ChatGPT process family: pointer movement becomes smooth.
• Reboot also clears it temporarily, but relaunching/using Codex can trigger it again.

Checks already performed

The following did not resolve it:

• Win+Ctrl+Shift+B graphics-stack reset
• restarting Explorer
• stopping NVIDIA Overlay and Epic EOS Overlay
• temporarily switching Windows to software-rendered cursor trails (MouseTrails=2, then reverted to 0)
• resetting Codex GPU-process priority to Normal
• clearing idle Codex computer-use Node helper processes

Additional observations:

• no CPU saturation or disk queue
• low DPC/interrupt time
• no recent Display/GPU, USB/HID, or WHEA events correlated with the symptom
• 5-second live sample of the Codex main process: only 0.047 CPU seconds (about 0.009 logical cores)
• bundled Chrome plugin is installed, but ~\.codex\plugins\cache\openai-bundled\chrome\latest remained stable across 20 samples/5 seconds (one unique target/timestamp), so this sample did not show the junction recreation loop

This looks like a high-refresh Windows cursor/DWM/GPU-composition regression associated with the app being open, and it can occur even when the Electron main process is effectively idle. Please investigate the app GPU process / hardware-cursor plane interaction, especially on hybrid Intel+iGPU/NVIDIA laptops at 240 Hz.

Independent Windows 10 confirmation on the same Codex build.

Environment

• Codex App: 26.810.4967.0 (OpenAI.Codex, Windows x64 MSIX)
• Windows 10 Pro 22H2 x64, build 10.0.19045.5854
• CPU: AMD Ryzen 9 7950X, 16 cores / 32 logical processors
• RAM: 127 GiB
• GPU: NVIDIA GeForce RTX 5070 Ti, driver 32.0.16.1062
• Display setup: three active monitor instances; reported video paths were 2560×1440 at 100/143 Hz
• Windows mouse trails: disabled (MouseTrails=0)

Symptom

This has occurred twice on this machine.

While moving the physical mouse continuously, the rendered Windows system pointer does not move smoothly. It briefly disappears for a few milliseconds and then reappears farther along the trajectory, producing a dotted/jumping appearance. The symptom is system-wide rather than limited to the Codex window.

During the latest occurrence, fully exiting Codex restored smooth cursor movement immediately. No mouse reconnect, driver reset, Windows restart, or hardware change was required.

Latest controlled observation

• Codex running: intermittent system-wide pointer disappearance/jumping.
• Fully exit Codex: pointer movement becomes smooth immediately.
• Present mouse devices reported OK in Windows.
• No correlated Display, nvlddmkm, DWM, WHEA, USB, or HID error event was found in the preceding six-hour Windows event-log window.
• PowerToys Mouse Highlighter and Mouse Pointer Crosshairs were not active.

The Codex process snapshot during the affected state contained 11 ChatGPT.exe processes plus codex.exe and codex-code-mode-host.exe. I did not capture a live CPU/disk/ETW trace before exiting the app, so I cannot attribute this occurrence to the high-CPU/cache loop described by some other reports.

Expected behavior

The Windows system pointer should remain continuously visible and track physical mouse movement smoothly while Codex is running.

Actual behavior

In the latest occurrence, the pointer intermittently disappeared and reappeared farther along its path while Codex was running; pointer movement became normal after Codex was fully exited.

Frequency / workaround

• Observed: twice.
• Observed recovery in the latest occurrence: fully exit Codex App.
• Exact onset trigger: unknown; the latest occurrence appeared after the app had been running for several hours.

/feedback session ID: _not captured during this occurrence; will add on the next recurrence if requested._

Independent confirmation with a privacy-safe live capture on the same Codex build.

Environment

• Codex Desktop: 26.810.4967.0 (OpenAI.Codex, Windows x64 MSIX)
• Windows 11 Pro 25H2 x64, build 26200.9168
• CPU: Intel Core i9-12900, 16 cores / 24 logical processors
• RAM: 64 GB
• GPUs:
• Intel UHD Graphics 770, driver 32.0.101.7088
• NVIDIA GeForce RTX 4070 Ti, driver 32.0.16.1088
• Two sampled displays: 2560×1440 at 99 Hz and 143 Hz

Symptom and recurrence

During an active, long Codex coding task, moving the mouse horizontally across Windows showed visible pauses along the pointer path. Normal video playback remained smooth while the pointer stuttered.

The behavior has recurred:

• A graphics-driver reset did not resolve an earlier occurrence.
• Fully closing Codex resolved that earlier occurrence immediately.
• Reopening Codex initially restored normal pointer movement, but the stutter later returned while Codex remained open.
• Pausing the only remaining background agent did not remove the signal or materially lower the busy Codex process.

Privacy-safe live measurements

At the user's “worst now” reproduction, a six-second sample showed:

• One Codex ChatGPT.exe process averaged 10.42% of total 24-thread CPU, equivalent to about 2.5 fully occupied logical processors.
• That process held 905.8 MiB working set, 1,284.0 MiB private memory, 58 threads, and 1,809 handles.
• Total system CPU was 15.34%.
• CPU DPC time was 0.32%; interrupt time was 0.52%; processor queue length was 1.0.
• 44.7 GiB physical memory remained available.
• Codex GPU-associated utilization averaged only 0.79% across the sampled engines.

A lighter ten-second sample while the symptom continued showed the same process averaging 5.42% total CPU and peaking at 8.33%, or roughly 1.3–2 occupied logical processors. After the remaining background agent was paused, a five-second sample still averaged 5.83% and peaked at 8.33%.

There was no overall CPU saturation, RAM pressure, processor queue, DPC/ISR storm, or Codex GPU saturation. The standout signal was one Codex desktop process continuously consuming multiple logical cores during the visible system-wide pointer stutter.

Scope and privacy

No browser content, URLs, window titles, account/contact data, command lines, screenshots, prompts, application logs, filesystem inventory, or process dumps were collected or uploaded. Only product/OS/hardware fields and aggregate process/system counters were sampled.

The exact internal cause is not proven. Please profile the busy Codex process during active long tasks and correlate renderer/main-thread scheduling, streaming UI updates, garbage collection, and cursor/compositor presentation latency. A built-in privacy-safe diagnostics export with process-role CPU/memory/GC/frame-timing data would make future captures substantially more useful.

Additional controlled variable from duplicate #38666:

The task-level Full access permission setting appears to be a repeatable trigger/mitigation boundary on the same running Windows installation:

• Full access enabled: severe system-wide mouse/input and Codex UI lag occurs, including in a new empty local task.
• Full access disabled: responsiveness returns immediately, without fully quitting or restarting Codex.
• Re-enabling/disabling the setting reproduced the relationship.

During the affected state, the extra load was concentrated in the Electron main process (roughly 1.3–1.4 logical CPU cores); renderer and GPU activity were low.

This suggests that the Full access permission/sandbox path is a key variable, rather than conversation length or an active task being required. The exact lower-level mechanism is not yet established. No raw logs, transcripts, account data, hardware identifiers, or private paths are included.

Independent confirmation on Windows 11 build 26200.9168, with a foreground-app A/B trace.

Environment

• Codex Desktop: 26.810.4967.0 (Windows x64 MSIX)
• Windows 11 Pro 25H2, build 26200.9168
• CPU: AMD Ryzen 9 9900X, 12 cores / 24 logical processors
• RAM: 30.9 GB
• GPU: NVIDIA GeForce RTX 5070 Ti, driver 32.0.15.9186 / 591.86
• Display: Samsung Odyssey G85SB, 3440x1440 at 174 Hz
• Mouse: Logitech MX Master 3S over Bluetooth

Symptom and controlled foreground test

The Windows pointer was visibly choppy in ordinary applications, but became smooth immediately while Task Manager was the selected foreground window. Merely leaving Task Manager open was insufficient; switching focus back to another app restored the choppiness.

A 123-second background trace recorded foreground-window transitions and per-process CPU deltas without bringing Task Manager forward:

• Notepad foreground: 48 seconds total, pointer choppy
• Task Manager foreground: 19 seconds total, pointer smooth
• Codex/ChatGPT main process stayed hot in both states:
• Notepad periods: 69.66 CPU-seconds / 48 seconds, about 1.45 logical cores
• Task Manager periods: 27.84 CPU-seconds / 19 seconds, about 1.47 logical cores

The busy process did not pause when Task Manager became foreground, so this did not behave like a process hiding from Task Manager.

A separate five-second process sample measured the main ChatGPT.exe process at:

• 7.547 CPU-seconds, about 1.51 logical cores
• 991.4 MiB working set
• 57 threads

System-level counters remained low during the affected state:

• Total CPU average: 13.72%, maximum 19.16%
• Disk time average: 0.19%
• DPC time average: 0.33%
• Interrupt time average: 0.41%
• Codex GPU peak in a separate five-second sample: 2.22%

No correlated Display/GPU, USB/HID, Bluetooth, or WHEA error was found in the recent Windows event-log window. Disabling the Samsung monitor's Game Mode/VRR path did not change the symptom.

A/B recovery

Fully terminating the Codex/ChatGPT process family made mouse movement smooth immediately. No mouse reconnect, Bluetooth reset, graphics reset, or Windows reboot was required.

Sanitized app-log signals

The affected session's desktop log contained repeated:

• ResizeObserver loop completed with undelivered notifications
• events routed to a hidden avatarOverlay renderer
• Conversation state not found / unknown-conversation event messages

I have not established that those log messages cause the CPU/input regression. Raw logs were not uploaded because they contain local paths, task IDs, and conversation metadata.

This independently reproduces the issue on the same app and Windows build as the original report and adds a controlled foreground-window trace showing that the main Electron process remains continuously busy even while Task Manager temporarily masks the visible cursor stutter.

Independent confirmation: the same cache-reconciliation loop is still present after the follow-up Windows app update to 26.810.6296.0.

Environment

• ChatGPT/Codex Desktop: 26.810.6296.0 (Windows x64 MSIX)
• Previous updates observed locally:
• 26.803.10989.0 → 26.810.4967.0 on 2026-08-14, when the system-wide mouse stutter began
• 26.810.4967.0 → 26.810.6296.0 on 2026-08-15; the issue persists
• Bundled Chrome integration cache: 26.810.50856
• Windows 11 Pro 25H2 x64, build 26200.9168
• Intel Core i5-13490F, 16 logical processors
• 32 GiB RAM
• NVIDIA GeForce RTX 5060 Ti, driver 610.62
• Three displays: 2560×1440 at 200 Hz plus two 1920×1080 at 60 Hz

Symptom and A/B result

While the app is running, mouse movement across Windows is visibly choppy. Fully exiting the complete ChatGPT/Codex process family restores smooth pointer movement immediately.

Five-second cache-loop confirmation

I sampled the junction metadata and the Electron main-process counters without collecting file contents, prompts, URLs, window titles, or command lines.

Over five seconds:

• ~/.codex/plugins/cache/openai-bundled/chrome/latest kept the same target
• The junction had 9 distinct creation/write timestamps, meaning it was recreated 8 times
• Electron main-process logical reads increased by 5.43 GiB
• Electron main-process CPU time increased by 7.94 seconds

This independently reproduces the feedback loop described above: the link target does not change, but the junction is repeatedly recreated while the main process rereads cached data.

Disk and memory clarification

A separate 62-second sample found:

• Process-level write-transfer rate: about 3.668 MiB/s
• Whole-system physical-disk write rate: only 0.285 MiB/s average
• App-data directory size change: approximately -0.002 MiB

So the very large process I/O counters are predominantly cache/IPC activity, not sustained physical SSD writes.

During the same sample:

• ChatGPT private memory fluctuated between about 1.81 and 2.45 GiB
• Thread count was unchanged
• Aggregate handle count changed by -2

That short sample does not show a monotonic memory leak. The main confirmed regression is the repeated cache reconciliation / logical read / CPU loop.

Additional checks showed low GPU utilization (about 1.5%), low DPC/interrupt time, and no correlated display-driver reset, GPU, or WHEA errors.

Please ensure the hotfix stops the watcher/reconciliation self-trigger, including on 26.810.6296.0, or provide a supported rollback/pinning path until fixed.

Privacy scope

This report intentionally excludes account/contact information, Windows usernames, absolute local paths, session/task IDs, LAN/remote-host details, raw logs, screenshots, prompts, and process dumps.

Independent confirmation on Windows 10: the cache-reconciliation feedback loop is still reproducible in 26.810.6296.0.

Environment

• Codex Desktop: 26.810.6296.0 (Windows x64 MSIX)
• Previous affected build observed locally: 26.810.4967.0
• Windows 10 Pro 22H2 x64, build 19045
• CPU: AMD Ryzen 5 PRO 4650G, 6 cores / 12 logical processors
• RAM: 31.3 GiB
• GPUs/displays:
• AMD Radeon Graphics, driver 31.0.21921.1000, 2560x1440 at 100 Hz
• NVIDIA GeForce RTX 4060 Ti, driver 32.0.15.9174 / 591.74, 2560x1440 at 143 Hz

Symptom and controlled A/B

While Codex is running, mouse movement intermittently pauses across the entire Windows desktop. Fully exiting the complete Codex/ChatGPT process family restores smooth mouse movement immediately.

The following did not resolve the stutter while Codex remained open:

• disabling NVIDIA Overlay / recording
• disabling AMD Radeon metrics overlay / recording
• disabling the Oray and ToDesk virtual display adapters

Five-second privacy-safe cache-loop capture

A 5.33-second sample of the top-level Electron ChatGPT.exe process and the bundled Chrome integration cache showed:

• CPU time increase: 7.47 seconds (about 1.40 continuously occupied logical cores)
• Logical reads: 3.89 GiB
• Logical writes: 2.05 MiB
• Working set at the end of the sample: 812.9 MiB
• chrome/latest junction target: 1 unique target
• Junction creation/write timestamps: 6 distinct values, indicating 5 recreations during the sample

This matches the previously described self-triggering cache-reconciliation loop: the target is unchanged, but the junction is repeatedly recreated while the main process rereads cached data. The physical disk queue remained at zero in earlier sampling, so the very high process I/O is predominantly cached/logical activity.

Windows reliability evidence

• Build 26.810.4967.0 produced a Windows MoAppHang / Application Hang 1002 event with hang type Top level window is idle on 2026-08-15.
• Windows Error Reporting also recorded RADAR_PRE_LEAK_64 for ChatGPT.exe on 2026-08-09.
• No correlated Display, NVIDIA, AMD, WHEA, disk, USB, or HID failure was found during the affected-state checks.

This confirms the regression on Windows 10 as well as Windows 11 and shows that 26.810.6296.0 has not fixed the Chrome integration cache loop. Please stop the watcher/reconciliation self-trigger or provide a supported temporary mitigation until a hotfix is available.

Privacy note: no prompts, conversation contents, account information, absolute user paths, URLs, window titles, raw logs, screenshots, or process dumps are included.

Additional independent A/B: --disable-gpu fully removes the stutter on 26.810.6296.0

I can consistently reproduce the system-wide pointer stutter on the follow-up Windows build 26.810.6296.0 (the latest version offered to this device during testing).

Same-machine A/B

1. Launch Codex normally: pointer movement becomes visibly jerky across Windows.
2. Fully exit the complete Codex/ChatGPT process family: pointer movement becomes smooth immediately.
3. Relaunch Codex normally: the stutter returns.
4. Fully exit again and launch the same executable with --disable-gpu: pointer movement is completely smooth.

The running Electron main process was verified to have the --disable-gpu argument. This result was repeatable without changing mouse, display, cache, overlay, driver, or power settings.

Environment

• Windows 11 Home 25H2 x64, build 26200.9168
• Hybrid graphics: NVIDIA GeForce RTX 5070 Laptop GPU + AMD Radeon 610M
• Two active displays: 240 Hz + 60 Hz
• Two independent pointing devices reproduced the normal-launch symptom:
• wired USB mouse
• built-in precision touchpad

Input and ETW evidence during normal launch

With each device moved continuously:

• Wired mouse, 20 s / 678 move events:
• Windows source interval p50 16 ms, p95 125 ms, max 313 ms
• 179 source gaps >=25 ms
• delivery excess max 16.157 ms; no delivery-excess spikes >=25 ms
• Touchpad, 15 s / 493 move events:
• source interval p95 125 ms, max 297 ms
• 138 source gaps >=25 ms
• no delivery-excess spikes >=25 ms

A synchronized elevated ETW/xperf trace (~27 s) had zero lost buffers/events. The largest individual DPCs were approximately:

• ndis.sys: 1004 us
• dxgkrnl.sys: 370 us
• Wdf01000.sys: 307 us
• nvlddmkm.sys: 238 us

No DPC/ISR stall was long enough to explain the recurring 100–125 ms gaps. CPU, memory, disk, and processor queue were not saturated, and no correlated USB/HID errors were found.

This does not prove whether the exact root cause is Chromium/Electron, DWM, the hybrid-GPU driver path, or mixed-refresh-rate composition. It does show that the GPU-accelerated path is a necessary trigger on this machine, while --disable-gpu is a reliable workaround.

I can provide additional sanitized aggregate traces if maintainers specify what would be most useful. Raw ETL/input logs are not attached because they contain local paths, process metadata, timestamps, and pointer coordinates.

thank you for your reports, we believe we've addressed this in 26.810.7004.0. try that version and send a fresh feedback if it persists!

Independent confirmation from another AMD Windows 11 system: the regression is still severe on the latest Microsoft Store build currently offered to this device, 26.810.6296.0.

Environment

• ChatGPT/Codex Desktop: 26.810.6296.0 (Windows x64 MSIX)
• Installed from Microsoft Store on 2026-08-15 at approximately 14:36 KST
• Windows 11 Pro x64, build 26200
• AMD Ryzen 9 5900X, 24 logical processors
• 64 GiB RAM
• AMD Radeon RX 7800 XT, driver 32.0.31035.1003

User-visible impact

• Launching Codex and starting normal work causes system-wide mouse movement to become visibly choppy.
• YouTube video playback in the browser also stutters while Codex is active.
• This is not limited to animation inside the Codex window.
• No codex-computer-use.exe process was running during the measurement.

Ten-second process sample

During the affected state:

• Electron main ChatGPT.exe: 137.81% of one logical core, 1,074.4 MiB working set, 1,831 handles, 58 threads
• Renderer ChatGPT.exe: 21.41% of one logical core, 523.6 MiB working set
• GPU-process ChatGPT.exe: 14.06% of one logical core, 209.4 MiB working set
• codex.exe app-server: 1.72% of one logical core
• Entire Codex/ChatGPT process family: 12 processes, 2,746.9 MiB working set, 8,165 handles, 400 threads, approximately 175.31% of one logical core
• DWM working set was approximately 825 MiB

The current desktop log did not contain the exact chrome_native_host_cache_reconcile_failed or chrome-plugin-app-server-runtime strings, so this report does not claim that the already-documented cache loop is definitely the only root cause. It confirms the same system-wide input/video symptom and main-process CPU pattern on another AMD desktop.

I saw the maintainer note that this is believed fixed in 26.810.7004.0. That build is not yet being offered to this device through Microsoft Store. Please expedite the Store rollout; the user will retest and submit fresh feedback if the issue persists on 26.810.7004.0.

Privacy note: no account data, usernames, prompts, conversation content, local paths, task IDs, raw logs, or process dumps are included.

Independent confirmation with an input-pipeline trace on another AMD/NVIDIA Windows 11 system.

Environment

• Codex Desktop MSIX: 26.810.4967.0
• Windows 11 Pro 25H2, build 26200.9168, x64
• CPU: AMD Ryzen 9 9950X3D2, 16 cores
• GPU: NVIDIA GeForce RTX 5080 + AMD integrated graphics
• Display: 3840 × 2160
• Two different wired USB mice; multiple USB ports tested

Symptom and isolation

The physical Windows pointer suddenly became visibly choppy system-wide, while normal video playback and an automatically animated/synthetic cursor remained smooth.

The symptom persisted after:

• swapping to a second wired mouse
• changing USB ports
• reconnecting the mouse
• disabling Windows animations
• resetting the graphics driver
• restarting the AMD USB controller
• closing unrelated game/overlay processes

Fully exiting the Codex/ChatGPT desktop process family restored smooth pointer movement immediately. Relaunching Codex also started in a smooth state.

Privacy-safe measurements

During the affected state:

• The Electron main ChatGPT.exe used 14.5 CPU-seconds over 10 seconds, equivalent to approximately 1.45 continuously occupied logical cores.
• One AboveNormal-priority main-process thread used 3.406 CPU-seconds over 5 seconds (about 68% of one logical core).
• A global physical-mouse event sample observed approximately 32.4 move events/s, with p95 gaps around 110 ms.
• A Win32k ETW trace showed pointer-motion events arriving in bursts separated by recurring 106–108 ms pauses, with those pauses occurring about every 224 ms on average.
• The trace therefore captured a real periodic input-path stall rather than a DPI or pointer-speed problem.

After fully exiting and relaunching Codex:

• Mouse movement was immediately smooth.
• The new Electron main process used only 0.359 CPU-seconds over 10 seconds (about 0.036 logical cores) during a comparable idle sample.

This is an independent controlled lifecycle A/B result on different hardware: affected Codex session running = periodic system-wide pointer stalls and a hot Electron main process; full exit/relaunch = immediate recovery.

I see the maintainer note that this is believed fixed in 26.810.7004.0. That build is not yet offered to this device through Microsoft Store, so I cannot validate the fix yet. I will retest and submit fresh feedback if the issue persists once 26.810.7004.0 is available.

No usernames, paths, task/session IDs, prompt contents, raw logs, or pointer coordinates are included.

Additional hypothesis: stale process/update lifecycle may amplify the regression

I want to add a hypothesis from repeated local observations. This is not proven as the root cause yet, but it may explain why the issue accumulates or becomes more likely after updates/restarts:

• After a clean Windows reboot, the first Codex launch is often smooth.
• After Codex has been restarted, or after an app update, the system-wide mouse stutter is much more likely to return.
• Updates sometimes appear to fail or not complete cleanly when an older Codex/ChatGPT process family has not fully exited. Repeated incomplete restarts may leave stale Electron/WebView/plugin state behind, so each cycle can make the next run worse.
• A full Windows reboot clears the condition temporarily; the first launch after that is again usually smooth.

There is also a local Windows AppX deployment clue: during the transition from 26.810.4967.0 to 26.810.6296.0, the AppX deployment log recorded error 0x80070015 while notifying the app's pre-launch service during install/uninstall. The deployment later registered the new package, so this event alone does not prove a failed update, but it is consistent with an update/lifecycle race worth investigating.

Please consider checking whether the updater fully terminates the entire ChatGPT/Electron/WebView child-process tree before replacing the package, and whether failed or interrupted updates can leave stale plugin/cache reconciliation workers running. A useful diagnostic would be to compare:

1. clean Windows reboot -> first launch;
2. normal app quit/relaunch without reboot;
3. update while any old ChatGPT.exe descendants remain;
4. full process-tree termination before update.

The previously reported Chrome cache-reconciliation loop remains the directly measured mechanism in the affected state; this comment is an additional lifecycle hypothesis that may explain why the condition is reset by reboot and worsens after repeated update/restart attempts.

Additional measurements from 26.814.5167.0 (Windows 11): analytics SQLite maintenance amplifies the stutter; input chain stalls while overall CPU stays low

Environment: Windows 11 Home 10.0.26200, Lenovo ThinkBook (21KU), 48 GB RAM, dual NVMe SSD; app 26.814.5167.0 (auto-updated 2026-08-17). Symptom matches this issue and #38546 / #38659: system-wide input stutter (mouse cursor included) lasting 3-15 s, self-recovering, several times per day while the app is running.

We ran a 1.5 s sampling loop for ~20 h logging total CPU, kernel interrupt/DPC %, per-process CPU deltas, and process spawns. Findings:

1. Every user-felt stutter (4/4 pinned to the minute) coincided with a ChatGPT.exe burst episode: one process sustaining ~1+ core for 15-50 s, matching the ~1.3-core main-process observation in this thread. No burst episode = no stutter reported.

1. The stall is confined to the input chain, not global scheduling. During stutters, kernel DPC/interrupt time stayed ~0%, total CPU stayed under ~25%, disk queues were empty, and our background sampling loop kept running on schedule while mouse input visibly lagged. This is consistent with the elevation observation in #38546 (low-level input hook chain stalling while the non-elevated app's process is busy).

1. Amplifier: the analytics store. ~/.codex/logs_2.sqlite had grown to 350 MB. Burst episodes coincided with checkpoint-style writes to it. After fully quitting the app, quarantining that file (the app rebuilt a 48 KB one on relaunch) and setting analytics.enabled = false in ~/.codex/config.toml, burst ticks dropped ~5x (37/hour -> 5-9/hour) and felt stutters dropped from several per day to ~1-2 per day.

1. Remaining triggers after that mitigation: app launch (~10 s of stalls), task/thread start (heavy loading of memories / thread DB / models cache — reproducible ~5 s stutter at the moment a task is kicked off), and individual agent turns while a task runs (20 s burst -> multi-second stutter).

Fully exiting the app (killing all ChatGPT.exe) restores smooth input immediately, consistent with the A/B in the original report.

Happy to provide the sampling CSVs if useful.