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

What version of the Codex App are you using?

26.810.4967.0 (Windows x64 MSIX)

Previous version: 26.803.10989.0

Platform

Windows 11 x64
Build 26200.9168
20 logical processors
Update installed at approximately 15:03 (UTC+8) on 2026-08-14

What happened?

Honestly, what the hell happened in this release?

Immediately after the desktop app updated to 26.810.4967.0, mouse movement across the entire Windows desktop became visibly choppy and unpleasant. This was not limited to the Codex window. Normal desktop interaction, window movement, and pointer movement all felt broken.

This is not a cosmetic UI issue. A coding app should not make the entire operating system feel unusable while it is open.

Controlled A/B confirmation

I completely exited Codex/ChatGPT and terminated the whole Codex ChatGPT.exe process family.

The mouse became smooth immediately.

Before exiting:

10 Codex-owned ChatGPT.exe processes were running.
The Electron main process showed sustained heavy CPU use, approximately 1.3 logical CPU cores during a live sample.
The lag affected the whole desktop, not only Codex.

After fully exiting:

The system-wide mouse stutter disappeared immediately.
No Bluetooth reconnect, mouse driver change, Logi software restart, or Windows reboot was required.

That is a very strong A/B result: Codex running = system stutters; Codex fully exited = system is smooth.

Steps to reproduce

Install/update the Windows Codex desktop app to 26.810.4967.0.
Launch Codex and leave it running.
Use it normally or keep a conversation open.
Observe system-wide mouse/input stutter.
Fully terminate all Codex-owned ChatGPT.exe processes.
Observe that mouse movement immediately returns to normal.

Expected behavior

Codex should remain responsive without consuming a CPU core or degrading input responsiveness across the entire operating system.

Actual behavior

The new build can make the whole Windows desktop stutter until Codex is completely terminated.

Please treat this as a serious Windows performance regression, not a minor animation problem. There are already several reports for the same build describing main-process CPU loops, renderer growth, disk-read loops, and system-wide input lag (#38506, #38510, #38518, #38544, #38547, #38551).

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

# Windows desktop app 26.810.4967.0 continuously uses high CPU after update, causing mouse and keyboard input lag #38551
Codex Windows 26.810.4967 idle main-process CPU busy loop in Chrome plugin app-server hashing #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

Launch Codex normally: pointer movement becomes visibly jerky across Windows.
Fully exit the complete Codex/ChatGPT process family: pointer movement becomes smooth immediately.
Relaunch Codex normally: the stutter returns.
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:

clean Windows reboot -> first launch;
normal app quit/relaunch without reboot;
update while any old ChatGPT.exe descendants remain;
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:

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.
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 [Windows] ChatGPT/Codex desktop app causes system-wide mouse stutter when running without elevation #38546 (low-level input hook chain stalling while the non-elevated app's process is busy).
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.
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.

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

Description

What version of the Codex App are you using?

Platform

What happened?

Controlled A/B confirmation

Steps to reproduce

Expected behavior

Actual behavior

Activity

github-actions commented on Aug 14, 2026

gteatsajoker commented on Aug 14, 2026

JimothySnicket commented on Aug 14, 2026

dinghaoxg-cpu commented on Aug 14, 2026

Environment

Distinct symptom

Controlled A/B

Checks already performed

Shimichi900 commented on Aug 14, 2026

Environment

Symptom

Latest controlled observation

Expected behavior

Actual behavior

Frequency / workaround

MCValentin commented on Aug 14, 2026

Environment

Symptom and recurrence

Privacy-safe live measurements

Scope and privacy

muyeecho commented on Aug 14, 2026

khanhng83 commented on Aug 15, 2026

Environment

Symptom and controlled foreground test

A/B recovery

Sanitized app-log signals

ryanleoyan commented on Aug 15, 2026

Environment

Symptom and A/B result

Five-second cache-loop confirmation

Disk and memory clarification

Privacy scope

Antony-Jia commented on Aug 15, 2026

Environment

Symptom and controlled A/B

Five-second privacy-safe cache-loop capture

Windows reliability evidence

YingboJiang commented on Aug 15, 2026

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

Same-machine A/B

Environment

Input and ETW evidence during normal launch

chess-oai commented on Aug 15, 2026

sjdmlgla commented on Aug 15, 2026

Environment

User-visible impact

Ten-second process sample

var-gg commented on Aug 15, 2026

Environment

Symptom and isolation

Privacy-safe measurements

Antony-Jia commented on Aug 15, 2026

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

waiting761 commented on Aug 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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