›_ Codex Issues
Codex Issues / #38716

[Windows][26.810.6296.0] Electron main process busy loop causes system-wide mouse stutter; full exit fixes it

Open 💬 7 comments Opened Aug 15, 2026 by RainyMarks
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

26.810.6296.0 (Microsoft Store package: OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0)

The regression appeared immediately after updating to this build.

What platform are you using?

  • Windows 11 Home, x64
  • OS version/build: 10.0.26200 / 26200
  • 16 logical processors
  • 63.4 GB RAM
  • NVIDIA GeForce RTX 5090 Laptop GPU, driver 32.0.16.1088
  • GameViewer Virtual Display Adapter is also present

What issue are you seeing?

After the latest Codex desktop update, keeping Codex open causes clearly visible system-wide mouse stutter. The pointer becomes choppy outside the Codex window as well.

Fully quitting Codex from the tray and terminating the complete ChatGPT.exe process family makes mouse movement smooth immediately. Reopening Codex makes the problem return. No mouse reconnect, graphics-driver reset, or Windows reboot is required for recovery.

This is a controlled application-lifecycle A/B result:

  • Codex running: system-wide mouse stutter.
  • Codex fully exited: mouse is immediately smooth.

Live process evidence from the affected state

  • 12 ChatGPT.exe processes were present.
  • Their combined working set was approximately 2.4-2.9 GB.
  • During a 10-second sample, aggregate ChatGPT.exe CPU time increased by approximately 13.5 CPU-seconds.
  • In a separate five-second per-process sample:
  • Electron main process: +6.92 CPU-seconds (~1.38 logical cores)
  • renderer process: +1.30 CPU-seconds
  • GPU process: +1.22 CPU-seconds
  • The root Electron process alone had approximately 2,000 handles.
  • The system has 16 logical processors and was not under general CPU or memory pressure.

The hot process is the root ChatGPT.exe Electron process, not the bundled codex.exe app-server process.

This is not the old taskkill.exe / WMI storm

I originally compared this with #34025, but the current reproduction is different:

  • Repeated sampling showed 0 live taskkill.exe processes.
  • conhost.exe count remained stable.
  • WmiPrvSE.exe CPU remained near zero.
  • The current desktop log did not contain the earlier electron-sampler / child-process-snapshot failure pattern.

The current failure is sustained CPU in the Electron main/renderer/GPU process family together with system-wide cursor stutter.

Steps to reproduce

  1. Update the Windows Codex desktop app to 26.810.6296.0.
  2. Launch Codex and use an existing local task normally.
  3. Leave the app running until mouse movement becomes visibly choppy across Windows.
  4. Observe sustained CPU accumulation in the root ChatGPT.exe process.
  5. Fully quit Codex from the system tray.
  6. Observe that mouse movement becomes smooth immediately.
  7. Reopen Codex and observe that the problem can return.

Regression context

This appears to be a continuation/regression of the Windows input-lag family reported in #38554, #38547, #33074, and #28855, but it reproduces on the newer 26.810.6296.0 package.

One existing investigation in #38554 suggests that Codex may register a global low-level mouse hook (WH_MOUSE_LL) on the Electron main thread. If that is correct, any busy loop or main-thread stall could delay mouse delivery across the entire OS. I have not independently proven the hook ownership on this machine, but the sustained root-process CPU and immediate full-exit recovery are consistent with that hypothesis.

Please investigate:

  1. Why the root Electron process continuously consumes roughly 1.3-1.4 logical cores in the affected state.
  2. Whether a WH_MOUSE_LL hook is installed on the busy Electron main thread and whether it is necessary.
  3. Main-thread event/IPC, hidden renderer (avatarOverlay / quick-chat), plugin reconciliation, and layout-update loops.
  4. A supported diagnostic/feature flag to disable the global hook or expensive background process discovery.
  5. A rollback/pinning option until a fixed Windows build is available.

Expected behavior

Codex should not install an input-path hook or perform background work in a way that makes the Windows pointer stutter system-wide. Idle/background operation should remain bounded, and fully exiting the app should not be the only reliable workaround.

Privacy

This report intentionally omits usernames, local paths, task IDs, prompt contents, and raw logs. Sanitized counters or additional targeted diagnostics can be provided if maintainers request them.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 13 days ago

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

  • #38713
  • #38659
  • #38554
  • #38547
  • #38711

Powered by Codex Action

ds-megogo · 13 days ago

Can confirm that I experience the same issue. Unusable.

Grauen · 13 days ago

Same here. BUT TLDR for those who are scrolling through this panicing:
File -> Quit ChatGPT -> Start it again -> Lag should be gone.

xuhanlin98 · 13 days ago

当前用的是 26.810.52044，同样的问题。体验感极差。关闭computes-ues貌似无法解决。

olinkluzz1v · 12 days ago

Independent reproduction on Windows 11 with the same Codex Desktop package, 26.810.6296.0.

Hardware:

  • Intel Core i7-12700K
  • 12 cores / 20 logical processors
  • 32 GB RAM
  • NVIDIA GPU

Symptoms:

  • During a very long-running local Codex task, the entire Windows desktop became severely choppy—subjectively similar to dropping from a smooth 200 FPS experience to roughly 10 FPS.
  • The lag affects mouse movement, window movement, and other applications, not only Codex.
  • Fully exiting Codex immediately restores normal system responsiveness.
  • Reopening Codex temporarily restores normal behavior.

The machine was not saturated during the affected state:

  • Total CPU: approximately 13%
  • Memory: approximately 42%
  • Disk: 0–2%
  • GPU: approximately 9%
  • CPU/GPU temperatures: approximately 38–51 °C

A read-only two-second process sample showed:

  • Hottest ChatGPT.exe: approximately 2.95 CPU-seconds over 2 wall-seconds, equivalent to roughly 1.48 continuously busy logical processors; working set approximately 658 MB.
  • codex.exe agent backend: approximately 0.06 CPU-seconds over the same interval; working set approximately 480 MB.
  • The ChatGPT/Codex process group was using approximately 2.1 GB in Task Manager.

The affected processes had affinity to all 20 logical processors (0xFFFFF), so this does not appear to be caused by Codex being restricted to the processor’s E-cores.

The long-running task may increase the likelihood of triggering the condition, but I cannot establish that it is required. The strongest reproducible boundary is:

  • Codex running in the affected state: severe system-wide stutter.
  • Codex fully exited: responsiveness immediately returns to normal.

No affinity, priority, cache, registry, or operating-system configuration changes were made during this observation.

znbsf · 12 days ago

Confirming the same regression on the exact Windows package.

Environment:

  • Codex Desktop: 26.810.6296.0
  • Windows 11 Pro x64, build 26200
  • GPU: AMD Radeon RX 9070 XT, driver 32.0.22042.14002
  • Virtual display adapters present: Meta Virtual Monitor and OrayIddDriver Device

Observed behavior:

  • After the latest update, mouse movement becomes visibly choppy while Codex Desktop is running.

A read-only five-second process sample during an active Codex session showed:

  • 11 ChatGPT.exe / codex.exe processes
  • approximately 2.59 GB combined working set
  • approximately 1.82 aggregate CPU cores
  • hottest ChatGPT.exe: approximately 1.02 CPU cores
  • codex.exe backend: approximately 0.02 CPU cores

Because a task was active during this sample, I am providing it as supplementary process evidence rather than an idle-state measurement. The virtual display adapters are listed as environmental data only; I am not claiming that they are the cause.

smigolsmigol · 12 days ago

I captured a 77 second WPR CPU and File I/O trace while the stutter was live on Desktop 26.810.4967.0. The main-process loop is now attributable to repeated integrity checks of the Chrome plugin app-server runtime.

Observed in the root ChatGPT.exe process:

  • 27,172,101,440 bytes across 51,836 I/O operations against the cached bundled codex.exe.
  • 26,974,145,856 bytes across 51,453 I/O operations against the .plugin-appserver copy of codex.exe.
  • Each executable is 295,151,920 bytes with matching size and timestamp. This is about 92 complete passes over each file in 77 seconds.
  • Live counters during the same failure ranged from 115% to 158% CPU, 0.94 to 1.82 GB/s logical reads, and 215K to 334K page faults/s.
  • The physical disk was not saturated. The I/O was attributed to the root Electron process, not the codex.exe app-server child.

The packaged Desktop code identifies this path as chrome-plugin-app-server-runtime. Its unchanged-file check recursively compares the staged runtime with the bundled runtime. For equal-sized files it computes SHA-256 using readFile(destination) and readFile(source). The checked set includes codex.exe, codex-code-mode-host.exe, the command runner, the Windows sandbox setup binary, and codex-resources.

There is no process-lifetime memoization or single-flight guard around that validation path. Repeated runtime reconciliation therefore rereads and hashes hundreds of megabytes on the Electron main process even when neither copy changed. WPA also shows a long-lived DirNotify on the hot main-process I/O thread, with repeated Read, Create, Cleanup, and Close activity.

The remaining unknown is which higher-level reconciliation trigger invokes the check about 1.2 times per second. The expensive operation itself is confirmed.

Suggested fix:

  1. Single-flight concurrent runtime validation.
  2. Cache successful validation by immutable build identity plus source and destination stat tuples.
  3. Rehash only after relevant metadata changes, or validate against the signed bundle digest rather than rereading both copies.
  4. Keep large-file hashing off the Electron main thread.
  5. Expose a supported temporary switch that disables Chrome native-host synchronization without disabling unrelated Codex functionality.

Does the reported fix in 26.810.7004 cover this validation path? If useful, I can provide the sanitized ETL-derived table layout and a narrower reproduction focused on Chrome plugin reconciliation.