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

[smlhd1993]

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

1. Install/update the Windows Codex desktop app to 26.810.4967.0.
2. Launch Codex and leave it running.
3. Use it normally or keep a conversation open.
4. Observe system-wide mouse/input stutter.
5. Fully terminate all Codex-owned ChatGPT.exe processes.
6. 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).

[github-actions]

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

[gteatsajoker]

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.

[JimothySnicket]

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.

[dinghaoxg-cpu]

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.

[Shimichi900]

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.

[MCValentin]

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.