›_ Codex Issues
Codex Issues / #38711

[Windows][26.810.4967.0] System-wide mouse stutter; hidden avatar overlay and cursor polling may contribute

Open 💬 4 comments Opened Aug 15, 2026 by 2batsloverandomartifactromps-dotcom
💡 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 (From “About Codex” dialog)?

  • Desktop app/product version reported by the running app: 26.810.41047
  • Windows MSIX package: OpenAI.Codex_26.810.4967.0_x64__2p2nqsd0c76g0
  • Embedded Chromium: 151.0.7922.137

What subscription do you have?

_Not included in the diagnostic capture._

What platform is your computer?

  • Windows 11, build 10.0.26200, x64
  • Intel Core Ultra 9 275HX (24 logical processors)
  • NVIDIA GeForce RTX 5080 Laptop GPU
  • 32 GB RAM

What issue are you seeing?

When the ChatGPT/Codex Windows desktop app is open—especially while a Codex task is active—mouse movement across Windows becomes jerky and less predictable. Fully quitting Codex improves mouse behavior immediately.

This initially appeared to coincide with the Computer History announcement, but Computer History is macOS-only and off by default. The local evidence instead points to a Windows desktop-app input/composition regression.

Read-only diagnostics on the affected machine found:

  • The Electron main process averaged about 142% of one CPU core over a 12-second sample, with the primary renderer averaging about 25% and the GPU process about 30% CPU.
  • Aggregate GPU 3D utilization was low, and Windows DPC/interrupt time was normal, so this was not conventional GPU saturation or a mouse-driver interrupt storm.
  • Codex maintains a second hidden Chromium window whose appearance is logged as avatarOverlay with rendererWindowVisible=false.
  • The hidden avatar-overlay renderer still receives duplicate task/reasoning activity updates while invisible.
  • The installed desktop bundle contains an avatar/native-composition pointer synchronization loop scheduled every 32 ms. It reads screen.getCursorScreenPoint(), evaluates pointer/button state, and sends synthetic mouseMove events into overlay surfaces.
  • The overlay composition window disables Chromium background throttling.
  • The bundle contains an avatarOverlayCpuOptimizations feature gate whose local fallback/default is false; the active server-side value could not be confirmed.
  • The Computer Use plugin is installed and enabled, and its native pipe is initialized at startup, but no Computer Use action/helper process was active and no mouse-control requests appeared in the current logs.

The overlay/pointer-sync path is a possible cause or contributor, not proven. In particular, related report #38546 says the desktop pet was disabled, so the underlying regression may be broader than the visible pet and could involve the always-prewarmed avatar renderer, native composition, or another Electron foreground/input path.

What steps can reproduce the bug?

  1. Fully exit the ChatGPT/Codex desktop app, including the tray/background process.
  2. Confirm mouse movement is smooth in Windows and other applications.
  3. Launch Codex Desktop normally.
  4. Start or resume a Codex task.
  5. Move the pointer across the desktop, File Explorer, Settings, and other ordinary applications.
  6. Observe jerky/stuttering pointer movement.
  7. Fully quit Codex again.
  8. Observe that pointer behavior improves immediately.

Useful isolation tests:

  1. In Settings → Pets, choose Tuck Away Pet, then fully restart the desktop app.
  2. If the issue persists, disable both Computer Use plugin toggles and restart.
  3. Compare CPU and pointer behavior with an active desktop task versus Codex CLI performing comparable work.

What is the expected behavior?

Running an active Codex desktop task should not alter, intercept, or degrade system-wide mouse movement or Windows desktop responsiveness.

Hidden/prewarmed overlay renderers should not continuously perform expensive cursor polling, native composition, or duplicate activity processing when they are not visible or needed.

Additional information

Feedback ID for OpenAI correlation:

01a00408-042a-7db2-a7fe-d7b774bfd7e6

Related reports:

  • #38546 — system-wide mouse stutter on Windows while the desktop app runs
  • #38710 — same 26.810.4967.0 package, active-thread trigger, system-wide pointer/composition degradation

Suggested maintainer checks:

  • Confirm whether avatarOverlayCpuOptimizations was enabled for this account/session.
  • Confirm whether the 32 ms pointer synchronization timer and native composition coordinator remain active while the avatar overlay renderer is hidden or the pet is tucked away.
  • Check whether duplicate activity delivery to the invisible avatar renderer is expected.
  • Compare Windows builds before and after 26.810.4967.0 for changes to Electron/Chromium input routing, DirectComposition, transparent always-on-top surfaces, and Computer Use native-pipe initialization.
  • Consider suspending/destroying the hidden overlay renderer and cursor polling when the pet/overlay is inactive.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 13 days ago

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

  • #38546
  • #38710
  • #38554
  • #38551
  • #38663

Powered by Codex Action

SAYUTIM · 12 days ago

I can reproduce this on a newer Windows build, and a per-process trace points to turn-boundary CPU/working-set thrashing in the primary renderer and Electron main process, rather than the hidden avatar renderer or conventional GPU saturation.

Environment

  • Windows 11 x64, build 10.0.26200
  • 16 GB RAM
  • Hybrid graphics: NVIDIA RTX 4050 Laptop GPU + AMD Radeon 680M
  • Current MSIX package: OpenAI.Codex_26.810.7004.0_x64__2p2nqsd0c76g0
  • The local app logs show an update/relaunch from 26.810.6296.0 to 26.810.7004.0 immediately before the regression was observed.

More specific reproduction pattern

The system-wide mouse stutter is reproducible at two turn boundaries:

  1. Submitting a prompt to Codex.
  2. The instant the assistant output completes.

Idle CPU is low. The spikes are concentrated around those events.

Per-process measurements

During a captured completion/input sequence (approximately 1.2-second sampling):

  • Primary visible renderer:
  • Peak CPU: 353% (about 3.5 logical cores)
  • Peak page faults: 30,990/sec
  • Working set: approximately 342 MB -> 446 MB
  • Electron main process:
  • Peak CPU: 165%
  • Peak page faults: 47,327/sec
  • Working set repeatedly changed approximately 118 MB -> 389 MB -> 119 MB
  • Peak I/O rate: approximately 11.4 MB/sec
  • Codex app-server:
  • Peak CPU: 60%
  • It was active, but not the dominant process.

Windows memory counters during an event also showed:

  • Page Reads/sec: approximately 497
  • Pages Input/sec: approximately 3,886
  • Transition Faults/sec: approximately 31,281
  • Available memory briefly fell to approximately 1.1 GB

This looks like a large amount of previously cold process state being touched and then aggressively trimmed, which explains why the effect is system-wide rather than limited to animation inside the Codex window.

Negative isolation results

  • Codex GPU 3D usage peaked around 8%; GPU copy around 3%.
  • The GPU process itself did not show a comparable CPU/page-fault spike.
  • The hidden renderers identified as the avatar/overlay renderers remained effectively idle during the captured turn-boundary spike.
  • The configured turn-ended notification helper returned in approximately 33 ms and was not correlated with the sustained spike.
  • DWM activity was comparatively steady rather than aligned with the large CPU/page-fault bursts.

So the avatar pointer-sync path described in this issue may be a separate contributor for some machines, but it was not the dominant path in this reproduction.

Possible maintainer investigation path

Inspection of the bundled/minified renderer code suggests that a turn update replaces the rendered-entry collection and invalidates memoized maps that scan the full set of turns/items. That is only an inference without ETW call stacks, but it matches the observed primary-renderer spike at turn/started / turn/completed. The main process simultaneously shows a large cold-working-set page-in/trim cycle.

It may be useful to check for:

  • Full-thread projection/reconciliation on every turn/started and turn/completed event.
  • Loss of structural sharing or memoization at turn completion.
  • Synchronous app-state snapshot, metrics, routing, or notification work on the main/UI critical path.
  • Large cold heaps being touched and immediately trimmed at turn boundaries.

I attempted a WPR GeneralProfile/GPU/DesktopComposition trace, but starting WPR required elevation on this machine, so the figures above come from process/performance-counter sampling rather than ETW stacks.

naipi11 · 12 days ago

Temporary no-restart workaround

Because this report already points to the hidden avatarOverlay, one additional state-reset step may help when the cursor stutter is active:

  1. Wake/open the Pet, even if it already appears tucked away.
  2. Wait until it is visibly displayed.
  3. Tuck Away Pet again.

On another Windows 11 / Codex 26.810.6296.0 system, that wake → tuck away cycle restored smooth mouse movement immediately in the same app process on every recurrence tested. No restart, elevation, service change, or driver reset was needed.

This is temporary—the issue can recur—but it is more targeted than restarting the entire app. Detailed same-process avatarOverlay evidence: https://github.com/openai/codex/issues/38546#issuecomment-5302228705

Independent confirmations: #38663 and #38745.

AbdullahAhmed · 12 days ago

Additional reproduction: keyboard jitter plus ~1 GiB/s non-disk main-process reads

I reproduced this on the same Windows app generation with both system-wide mouse jitter and uneven/delayed keyboard input.

Environment
  • MSIX package: OpenAI.Codex 26.810.6296.0
  • Windows 11 Pro 10.0.26200, x64
  • Intel i9-13900H, 32 GiB RAM
  • Hybrid graphics: Intel Iris Xe + NVIDIA RTX 4070 Laptop GPU
  • Displays: 2560x1600 at 240 Hz plus 1920x1080 at 60 Hz
Measurements in the degraded state
  • Electron main process: approximately 91-136% CPU (PerfProc scale) and about 1.0 GiB private memory.
  • GetProcessIoCounters showed 872-974 MiB/s in main-process read-transfer rate.
  • Physical disk reads remained approximately 0.01 MiB/s, with a measured maximum near 0.12 MiB/s.
  • Monitoring the app's open disk file handles showed no file position advancing at a corresponding rate.
  • This therefore appears to be IPC/pipe/device/composition or another cached/shared path, not disk throughput.
  • Overall system counters were healthy: CPU 25.8% average, DPC 0.35%, interrupt time 0.54%, processor queue max 1, approximately 15.9 GiB RAM available, and negligible pagefile use.
  • Active Codex session files totaled only approximately 0.12 GiB; the diagnostic chat itself was approximately 2 MiB, so a giant active chat did not explain this occurrence.

For scale only—not proof—a 2560 x 1600 x 4-byte surface at 60 fps is approximately 937.5 MiB/s, very close to the observed process read-transfer rate.

Log totals from the affected process

Across its two main desktop-log segments:

| Signature | Count |
| --- | ---: |
| main_thread_jank_snapshot | 25 |
| ResizeObserver loop completed with undelivered notifications | 203 |
| Events delivered to hidden rendererWindowAppearance=avatarOverlay | 11,020 |
| unknown conversation | 3,576 |

The invisible avatar renderer received reasoning-summary and turn events throughout the session. Raw logs are not attached because they include local paths and task metadata.

This overlaps with the renderer/layout symptoms in #33996, but the approximately 1 GiB/s non-disk main-process read signature and system-wide keyboard impact may help distinguish the pathological state.

State experiment

The persisted state had 11 entries in electron-remote-hosted-pip-task-visibility-state, all marked shown, plus stale overlay bounds.

I backed up the state, set electron-avatar-overlay-open=false, and cleared the PiP task map. After a full app quit/relaunch, Codex removed the explicit closed flag and repopulated all 11 task entries. That persisted edit is therefore not a durable fix.

Before/after full restart

A full tray quit and relaunch of the same app version immediately improved mouse and keyboard behavior.

In a 20-second post-restart sample:

  • Main-process reads: 0.10 MiB/s average, 0.78 MiB/s max.
  • Main-process CPU: 8.6% average, 27% max.
  • Hidden overlay renderer: 0% average CPU.
  • New jank snapshots: 0.
  • New ResizeObserver errors: 0.
  • New avatar-overlay events: 0.
  • New unknown-conversation events: 0.

The restart log did have a short initialization burst before settling (1 jank snapshot, 35 ResizeObserver errors, 109 avatar events, 22 unknown-conversation events). The important distinction is that these signatures stopped in the subsequent live-rate window rather than continuing or escalating.

Interpretation

This strengthens the correlation with a hidden overlay/event/composition path, but does not prove it is the sole root cause. A reasoning-summary/layout feedback loop may be a contributor, and the normal post-restart app still prewarms the hidden overlay.

Potential maintainer checks:

  • Instrument the source of Electron main-process read transfers when they approach 1 GiB/s.
  • Confirm whether hidden avatar/native-composition surfaces or cursor polling remain active when the Pet is tucked away.
  • Stop unnecessary duplicate turn/reasoning delivery to an invisible overlay renderer.
  • Check why the invisible PiP roster is repopulated with many tasks at startup.
  • Correlate turn/reasoning updates with ResizeObserver layout mutation.
  • Test avatarOverlayCpuOptimizations and mixed-refresh hybrid-GPU systems.

A full tray quit/relaunch is currently an effective but temporary workaround. The wake-Pet -> tuck-away cycle already documented above is a useful same-process workaround to try on recurrence.