[Windows] Invisible avatarOverlay causes system-wide mouse cursor stutter on AMD 780M

Summary

After Codex has been running for a short time, the physical mouse cursor starts moving in visible jumps across the entire Windows desktop. The stutter continues even when Codex is idle and CPU/disk load is low. Fully exiting Codex stops it immediately.

The issue was isolated to Codex's invisible transparent avatarOverlay window:

1. Restarting only Codex's GPU process made the cursor immediately smooth, but the stutter returned after about 20–30 seconds.
2. Closing the hidden avatarOverlay window, then restarting the same GPU process, made cursor movement remain smooth.
3. Removing selected-avatar-id = 'null-signal' from C:\Users\cioci\.codex\config.toml prevented the overlay from being recreated. The cursor remained smooth.

This looks like an Electron/Chromium GPU-composition interaction involving the invisible layered/click-through avatar window, AMD Radeon 780M, 120 Hz, and 175% display scaling.

Environment

• Device: Lenovo ThinkBook 16 G6+ AHP
• Lenovo model: 21LG
• Device identifying number: MP2NP6FG
• Windows user profile: C:\Users\cioci
• OS: Windows 11 Pro, 64-bit
• OS version/build: 10.0.26200 / 26200
• CPU: AMD Ryzen 7 8845H, 8 cores / 16 logical processors
• RAM: approximately 29.9 GB
• GPU: AMD Radeon 780M Graphics
• GPU driver: 32.0.11039.6002
• GPU driver date: 2024-12-02
• Display: 2560 × 1600, 120 Hz
• Windows scale factor observed in renderer command line: 1.75 (175%)
• Power plan: High performance
• External mouse: USB VID_258A / PID_2031
• Touchpad: ELAN I2C
• Both input devices reported status OK
• Codex package: OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0
• Codex package version: 26.810.6296.0
• Executable: C:\Program Files\WindowsApps\OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe
• Embedded Chromium/Electron executable version: 151.0.7922.137
• Codex log directory: C:\Users\cioci\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\08\15
• Report timestamp: 2026-08-15, Europe/Istanbul (UTC+03:00)

Reproduction

1. Reboot Windows.
2. Before launching Codex, move the mouse: movement is smooth.
3. Launch Codex with an avatar selected:

``toml
[desktop]
selected-avatar-id = 'null-signal'
avatar-overlay-mascot-width-px = 138
``

1. Use Codex for some time.
2. Stop active reasoning and leave Codex idle.
3. Move the pointer across Codex and other Windows applications.

Actual result

The physical mouse cursor moves in jumps/stutters system-wide, despite no obvious resource saturation. The stutter persists while Codex is idle. Fully unloading Codex stops it immediately.

Expected result

An invisible/hidden avatar overlay must not affect Windows cursor presentation or desktop composition.

System-load checks while the problem was present

15-second baseline:

| Counter | Average | Maximum |
|---|---:|---:|
| Total CPU | 14.20% | 19.22% |
| DPC time | 0.23% | 1.65% |
| Interrupt time | 0.25% | 0.78% |
| Processor queue length | 0 | 0 |
| Average disk queue length | 0.01 | 0.03 |
| Available memory | 12,489 MB | 12,774 MB |
| Pages input/sec | 0.86 | 2.96 |

A later 10-second check after the workaround also showed low DPC/interrupt/disk queues:

• DPC average/max: 0.281% / 0.677%
• Interrupt average/max: 0.280% / 0.678%
• Processor queue: 0
• Disk queue average/max: 0.012 / 0.034

This does not resemble CPU starvation, paging, disk contention, or a generic HID/DPC problem.

Process and GPU observations

Codex process tree included:

• Electron main process
• dedicated --type=gpu-process
• multiple renderers
• utility/network/storage processes
• bundled codex.exe app server

Before the first GPU reset:

• Codex main PID: 5760
• Codex GPU PID: 19540
• GPU-process private memory: approximately 586 MB
• GPU-process handles: 2,745
• GPU 3D utilization while nominally idle: average approximately 0.98%, max approximately 2.34%
• DWM PID: 2416
• DWM private memory: approximately 942–988 MB
• DWM handles: approximately 3,360
• Codex used hardware GPU acceleration; no --disable-gpu argument was present.

Renderer command lines included:

• --device-scale-factor=1.75
• --num-raster-threads=4
• --enable-features=ReportStuckThrottle
• --disable-features=DropInputEventsWhilePaintHolding,...

A/B test 1: GPU process reset only

• Terminated only Codex GPU PID 19540.
• Codex immediately created replacement GPU PID 37768.
• Main Codex process and the active task remained alive.
• Cursor movement became immediately smooth.
• After approximately 20–30 seconds, the same cursor stutter returned.

This strongly implicated the Codex GPU/composition path but showed that restarting the GPU process alone was not a durable fix.

Hidden avatar overlay evidence

The Codex main process owned this top-level window while the avatar was not visibly shown:

Handle      : 0x1405B2
Title       : Codex
Class       : Chrome_WidgetWin_1
Visible     : False
Position    : (-12, 344)
Size        : 434 × 413
ExStyle     : 0x2800A8
Layered     : True
Transparent : True
ToolWindow  : True

So Codex retained a hidden, layered, click-through tool window for the avatar.

Codex logs also repeatedly referenced an invisible avatar window:

rendererWindowAppearance=avatarOverlay
rendererWindowFocused=false
rendererWindowId=2
rendererWindowVisible=false

The invisible avatar renderer still participated in periodic feature/config refresh work. A same-day log also recorded repeated main-renderer errors:

[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.

One observed log filename was:

C:\Users\cioci\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\08\15\codex-desktop-50ea4197-dc2b-4aab-a8b3-7bbfc00a1799-9876-t0-i1-000200-0.log

A/B test 2: close avatarOverlay, then reset GPU

1. Sent WM_CLOSE only to the hidden transparent avatar window.
2. Confirmed the main Codex window/task remained alive.
3. Terminated only GPU PID 37768.
4. Codex created replacement GPU PID 20940.
5. Monitored the new process for 45 seconds.

Selected samples:

| Seconds | Private MB | Working set MB | Handles | Threads | CPU seconds |
|---:|---:|---:|---:|---:|---:|
| 0 | 344.7 | 106.8 | 1,417 | 37 | 0.77 |
| 10 | 301.0 | 109.2 | 1,413 | 39 | 1.53 |
| 20 | 229.5 | 109.7 | 1,419 | 39 | 1.69 |
| 30 | 247.7 | 113.3 | 1,416 | 40 | 2.31 |
| 40 | 433.4 | 118.3 | 1,416 | 40 | 3.34 |
| 44 | 445.5 | 121.5 | 1,418 | 40 | 3.89 |

Private memory continued to fluctuate/grow, but handle count remained stable. Most importantly, cursor movement stayed smooth beyond the previous 20–30 second failure point. The user explicitly confirmed: “плавность держится стабильно, фризы прекратились” (“smoothness remains stable; the freezes stopped”).

This distinguishes the overlay/composition behavior from a simple GPU-process handle leak.

Durable local workaround

Removed this line from C:\Users\cioci\.codex\config.toml:

selected-avatar-id = 'null-signal'

The avatar-overlay-mascot-width-px = 138 value remains but has no selected avatar.

After waiting and rechecking all top-level windows owned by Codex, only the ordinary non-layered main window remained:

Visible     : True
Title       : ChatGPT
Layered     : False
Transparent : False
ToolWindow  : False

The hidden layered/transparent Codex avatar window did not reappear, and cursor movement remained smooth. Hardware acceleration for the main application was not disabled.

Ruled-out separate issue

Earlier in the investigation, the main Electron process was repeatedly reading/hashing bundled Chrome-plugin binaries. A 10-second FileIO trace observed approximately:

• local cached plugin codex.exe: 13.64 GB logical reads
• plugin-appserver codex.exe: 13.51 GB logical reads
• code-mode host copies: approximately 5.4 GB combined
• total: approximately 33 GB logical reads in 10 seconds
• approximately 48 repeated cycles in that interval

Disabling chrome@openai-bundled in C:\Users\cioci\.codex\config.toml stopped that excessive file-I/O behavior. However, the mouse stutter still reproduced later while Codex was idle and system load was low, so that file-I/O loop was a separate bug and not the root cause of this cursor issue.

The in-app browser@openai-bundled plugin remained enabled.

Requested fix

• Do not create/retain the avatar overlay window when the avatar is hidden.
• Fully suspend or destroy the avatar renderer/composition surface while invisible.
• Investigate the Windows layered/click-through overlay's interaction with Chromium 151, DWM, AMD Radeon 780M, 120 Hz refresh, and 175% scale.
• Consider a visible setting to disable the avatar overlay without editing config.toml.
• If the overlay must remain alive, ensure it does not keep a GPU surface/compositor path active while rendererWindowVisible=false.

A privileged WPR GPU/DesktopComposition trace was attempted, but the current Codex process did not have permission to enable the system-performance profile. No ETL was produced.

The reporter explicitly consents to publication of the environment and device details above and accepts the associated anonymity/privacy risk.