Windows: pet/avatar overlay makes task switching and mouse dragging freeze

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

• #33375
• #33518
• #33494
• #33525
• #33561

Powered by Codex Action

Additional isolation results from my Windows setup:

• Codex Desktop: 26.707.12708.0
• Windows 11 Home 25H2, build 26200.8875
• With the Pet hidden/Default, Codex remains responsive.
• With the built-in Standard Pet visible, the cursor and desktop UI stutter during response generation and shortly after startup.
• The same behavior occurs with custom pets, so it does not appear to be specific to a custom pet asset or pet version.
• Windows Animation Effects / Reduced Motion did not resolve the stutter.
• With Codex fully closed, streaming a 50-line response on chatgpt.com in Chrome caused no stutter.
• ESET remained enabled, with SSL/TLS scanning ignored only for ChatGPT.exe.
• During this Pet-only reproduction, no serialport.node errors and no Event ID 1000/1001/1002 crashes were observed.

This suggests that the Pet/avatarOverlay rendering itself is sufficient to trigger the stutter, separately from the earlier ESET/serialport crash issue.

Expected behavior:
Keeping a Pet visible should not degrade cursor movement or desktop UI responsiveness.

Have this issue aswell

• Codex Desktop package: 26.715.2305.0
• Windows 11 Pro 25H2, build 26200.8875
• AMD Ryzen 7 9800X3D, Gigabyte X870E AORUS PRO, 32 GB RAM
• The issue began immediately after updating the Codex desktop app today.
• With the Pet hidden, or with Codex fully closed, mouse input remains smooth.
• With a Codex task actively running and the Pet visible, physical mouse input periodically freezes across the entire Windows desktop.
• Each freeze lasts approximately half a second and generally repeats around every 30 seconds.
• This is not limited to dragging inside Codex. It affects mouse movement and clicks in other applications and games as well.
• The rest of the system continues running during each stall. For example, a game continues rendering and character movement continues, but mouse movement and clicks are briefly ignored.
• The behavior reproduces with both a Logitech G Pro X Superlight 2 and a separate wired mouse, so it does not appear to be specific to the mouse, receiver, polling rate, or wireless connection.
• LatencyMon was running during one observed mouse stall and did not record a significant DPC or ISR latency spike, suggesting this is not a conventional whole-system driver latency stall.
• I also reproduced the issue after testing with non-Microsoft startup services disabled and after ruling out several unrelated mouse, RGB, and hardware-monitoring components.

This appears consistent with the Pet/avatar overlay triggering periodic system-wide input stalls specifically while an agent task is active. In my case, it is not limited to slow rendering or task switching within the Codex window.

Expected behavior:

Keeping the Pet visible while a task runs should not interrupt physical mouse input or degrade responsiveness elsewhere in Windows.

I’m experiencing the same severe mouse lag and performance problems when Codex Pets is enabled.

My system is a Windows 11 desktop/tower PC with an NVIDIA RTX 5080, Intel Core Ultra 9 processor and 32 GB DDR5 RAM. This is a dedicated desktop GPU rather than a laptop with hybrid graphics. Disabling the pet resolves the problem.

Also reproducing on Windows with Codex Desktop package 26.715.4045.0.

In this case the pet was enabled unintentionally because the account menu shifted while trying to click Remaining usage (the UX path discussed in #32069). Once the pet appeared, the computer became noticeably laggy.

This links the performance problem to a frequent account-menu action: a layout-shift misclick can enable an overlay that immediately degrades system responsiveness. Expected behavior is that the pet overlay should not make the computer lag, and users should be able to disable the pet entry persistently.

Additional Windows data point: the pet/avatar overlay can still affect mouse input even after it appears to be disabled/hidden.

Environment:

• Codex Desktop package: 26.715.4045.0
• ChatGPT.exe file version: 150.0.7871.124
• OS: Windows 11 Pro for Workstations, build 26200
• GPU: NVIDIA GeForce RTX 4060 Ti, driver 32.0.16.1074, primary display 2560x1440 @ 299 Hz
• Also present: AMD integrated graphics, driver 32.0.21043.19003

Observed behavior:

• The pet was turned off/hidden in the UI and was not visible on screen.
• Codex still caused periodic system-wide mouse freezes / input stutter.
• Enumerating top-level Win32 windows for ChatGPT.exe showed a hidden Electron/Chromium window that looked like the pet overlay:
• title: Codex
• class: Chrome_WidgetWin_1
• size: 408 x 400
• visibility: false
• owned by the main ChatGPT.exe process
• There was no separate pet, avatar, or overlay process; the residual overlay window was inside ChatGPT.exe.

Isolation result:

• Sending WM_CLOSE only to that hidden Codex 408x400 window removed it from the window list.
• ChatGPT.exe / Codex stayed running.
• Mouse stutter stopped immediately after that hidden window was closed.

This suggests the UI toggle may hide the pet/avatar overlay window without destroying it, and the hidden overlay window can still participate in Chromium/GPU/DWM/input handling enough to cause system-wide mouse stalls.

One extra note: this machine also had many MCP/tool child processes at the time, but the stutter stopped after closing only the hidden pet window, without killing the main app or changing MCP configuration. So the hidden overlay window appears to be independently capable of triggering the lag on this setup.

I can reproduce the same issue on a newer Windows desktop build.

Environment

• Codex / ChatGPT desktop package: OpenAI.Codex 26.810.4967.0
• Platform: Windows

Reproduction and A/B result

1. Show/enable a Pet.
2. Keep the ChatGPT/Codex window in the foreground, particularly while a Codex turn is active.
3. Mouse movement becomes visibly choppy/system-wide.
4. Focus any other application: mouse movement immediately becomes smooth.
5. Return to Codex and choose Settings > Pets > Tuck Away Pet: the stutter immediately and consistently disappears.

This makes the Pet overlay a strong causal trigger rather than general Codex background work.

Performance samples while affected

• Main ChatGPT.exe process: approximately 100–126% Processor Time (about one full logical CPU core)
• Additional ChatGPT renderer process: approximately 15–34%
• Desktop Window Manager (dwm.exe): approximately 14–20%
• ChatGPT 3D GPU engine: only approximately 1–4%

The foreground-only behavior plus high CPU and relatively low GPU usage suggests a high-frequency Pet animation/render loop or a software-rendering path. Backgrounding the window appears to throttle that rendering work.

Workaround

Use Tuck Away Pet. This fully resolves the mouse stutter in this reproduction.

No raw logs, files, user paths, or session transcript are attached.

I can reproduce a system-wide mouse/input regression on the current Windows desktop build, even with the Pet tucked away.

Environment

• Codex / ChatGPT desktop package: OpenAI.Codex 26.810.4967.0
• Platform: Windows
• Mouse: Razer DeathAdder Essential (wired), connected through the case front-panel USB
• The same mouse and USB connection worked normally before this update
• Pet is closed/tucked away and not visible

Reproduction and behavior

1. The problem started immediately after updating Codex on Aug 14, 2026.
2. Use Codex normally for some time with the Pet hidden.
3. Physical mouse movement and clicks across the entire Windows desktop become intermittently choppy/unresponsive.
4. CPU and GPU show no meaningful sustained load while the stalls occur.
5. Fully exiting Codex immediately restores smooth mouse input.

This is not limited to rendering or interaction inside the Codex window. The unchanged hardware worked correctly before the update, so the app update is the trigger.

The running app loads hid-topology-watcher.node, Windows HID.DLL, and the WorkLouder device-kit / serialport native binding. I did not observe a corresponding Codex application crash in Windows Event Viewer. This may be related to a residual hidden Pet overlay or native HID/device-topology polling, but that is only a hypothesis.

Expected behavior

Codex should never stall system-wide physical mouse input, including when the Pet is hidden.

No raw logs, user paths, files, or conversation data are attached.

During an affected session, I found a hidden ChatGPT.exe top-level window titled Codex, class Chrome_WidgetWin_1, size 419x411, visible=false. Sending WM_CLOSE only to that hidden window removed it while the main Codex window and active task remained running. System-wide mouse stutter stopped immediately.

Additional controlled reproduction on the current Windows build, with a few
A/B results that may help separate the overlay/input symptom from the concurrent
main-process CPU regression.

Environment:

• Codex / ChatGPT About: 26.810.41047
• Package: OpenAI.Codex 26.810.4967.0
• Windows NT 10.0.26200.0 x64
• RTX 3080
• Primary: 2560x1440 @ 239.97 Hz, VRR enabled, HDR on
• Secondary: 2560x1440 @ 120 Hz

I reproduced sustained system-wide mouse stutter with the Pet visually hidden.

During the affected state there was a hidden top-level window:

• title: Codex
• class: Chrome_WidgetWin_1
• size: 408x400
• visible: false
• layered / transparent / topmost / tool-window
• not DWM-cloaked

I sent WM_CLOSE only to that hidden window. It disappeared, the main ChatGPT
window and application remained running, and the system-wide mouse stutter
stopped immediately and did not return during subsequent observation.

A useful control is that the hidden 408x400 window is not sufficient by itself:
I also observed it throughout known-smooth operation with the same static window
properties.

There is a lifecycle difference between "persisted hidden" and explicitly
tucking the Pet in this build:

• launching with the Pet already visually tucked still creates the hidden

408x400 Codex window;

• explicitly choosing Tuck Away during that process destroys the window;
• restarting recreates a new hidden 408x400 window even though the Pet remains

visually tucked.

I also captured the concurrent main-process CPU behavior. During the bad
recurrence, main-process CPU remained above 100% for about 14.6 seconds.
However, after closing only the hidden overlay and eliminating the mouse
stutter, the main ChatGPT process was still using about 136% CPU.

So in this reproduction the cursor symptom and sustained main-process CPU
condition were separable: destroying the hidden overlay fixed the cursor
stutter without stopping the CPU condition. That CPU behavior may therefore
overlap with #38547 rather than fully explain the overlay/input symptom.

One other A/B result while the stutter was active:

• elevated PowerShell focused: smooth
• elevated MMC focused: smooth
• normal Notepad: stutter
• non-elevated PowerShell: stutter
• non-elevated PowerShell made topmost: stutter

So ordinary focus or topmost state alone did not suppress the symptom.

This also seems relevant to the avatar-overlay lifecycle described in #36980.

I retained raw sampler/log evidence locally but am not attaching it because it
contains local telemetry.

Follow-up: I was able to independently reproduce the same isolation result in
a second affected session.

This recurrence began naturally after extended normal use. I had not opened
Settings, changed Pet visibility, or otherwise interacted with the Pet during
that session.

During sustained system-wide mouse stutter:

• the ChatGPT main process averaged about 138% CPU over 30 seconds
• GPU-process CPU averaged about 1.3%
• a hidden top-level Codex / Chrome_WidgetWin_1 window was again present
• it was 408x400 and visible=false

I again sent WM_CLOSE only to that hidden Codex window.

Result:

• the hidden window disappeared
• the main ChatGPT application remained running
• system-wide mouse stutter stopped immediately
• the cursor remained smooth throughout a subsequent 30-second observation

Importantly, after the overlay was destroyed, the main ChatGPT process was
still using about 136% CPU.

I then measured approximately 16.3 GB of process reads over 10 seconds
(~1.63 GB/s) while:

• the hidden overlay was absent
• the cursor was smooth
• the main-process CPU fault was still active

I captured a built-in performance trace in exactly that separated state.
Sanitized analysis showed approximately:

• 73k ThreadControllerImpl::RunTask events
• 64k RunMicrotasks events
• heavy V8 incremental/major GC activity
• update: ~7.27 s CPU
• createUnsafeArrayBuffer: ~5.50 s CPU
• additional readFileHandle, createUnsafeBuffer, Hash, digest,

and allocUnsafeSlow activity

• source metadata included node:internal/fs/promises,

node:internal/buffer, and node:internal/crypto/hash

That main-process behavior appears closely related to #38547.

The useful distinction is that the cursor symptom was removed while this
high-CPU/read/hash/buffer activity continued.

This is now two independent affected sessions where destroying only the hidden
Pet/avatar overlay immediately removed the system-wide cursor stutter.

Raw sampler and performance-trace data remain local because they contain
potentially sensitive telemetry.

Follow-up on the newer build, with the two symptoms isolated:

Environment

• Codex desktop package: OpenAI.Codex 26.810.6296.0 x64
• Windows 11 x64

After sending WM_CLOSE only to the hidden Codex / Chrome_WidgetWin_1 overlay window, the system-wide mouse stutter stopped immediately while the main app and active task remained running. However, a separate Codex-local responsiveness problem remained: typing in the composer and dragging the main Codex window were still visibly laggy.

Measurements in that separated state

• Main ChatGPT.exe averaged approximately 133–157% CPU across multiple idle samples.
• The main UI thread (the thread that owns the visible ChatGPT / Chrome_WidgetWin_1 window) used approximately 65% of one logical core, with roughly 2.8k context switches/s.
• GPU process and renderer processes were near idle; DWM was not elevated.
• Minimizing the main window for 5 seconds did not reduce the main-process CPU condition (still approximately 136%).
• No concurrent PowerShell/Git/WMI process storm was observed.
• The main process had loaded both the WorkLouder serialport binding (@serialport/bindings-cpp/.../bindings.node) and native/hid-topology-watcher.node.
• No Crashpad dumps or matching Windows Application Error events were present in this session, so I cannot confirm that this is the exact serialport crash-loop variant reported in #33518.

This independently confirms the separability noted above: destroying the hidden Pet/avatar overlay fixes the system-wide cursor symptom, but does not fix the persistent Electron main/UI-thread loop that makes typing and window dragging laggy. The latter may overlap with #38547 and/or the Codex Micro native HID/device service.

A useful short-term mitigation would be a supported toggle/feature gate to fully disable Codex Micro/native HID monitoring on Windows systems without the hardware. Please also investigate the main UI-thread loop in 26.810.6296.0.

[Windows Desktop] Sustained high CPU and mouse stutter while Pet is tucked away; hidden avatar overlay remains active

Summary

Codex Desktop for Windows entered a sustained high-CPU state while the Pet was configured as Tuck Away. The Electron main process (ChatGPT.exe, inside the Codex package) and a renderer process consumed substantial CPU while avatar-overlay logs reported rendererWindowVisible=false. The mouse visibly stuttered. Fully quitting Codex stopped the problem.

The problem was observed again after updating Codex and rebooting Windows. CPU was initially low after reboot, then rose later while the persisted Pet state still said closed. A deterministic minimal reproduction has not yet been established.

Existing tracker

• Canonical issue: openai/codex#33565 (open; labels include performance, pets, and windows-os).
• Near-identical system-wide mouse-freeze report: #33840, closed as a duplicate of #33565.
• Related sustained desktop-main-process CPU report: #30021 (open).
• Supporting evidence that a hidden avatarOverlay renderer can keep receiving task events: #35948 (different bug; not evidence of this root cause).

The new evidence in this report is that the problem persists with the Pet state explicitly set to tucked/false, while hidden avatar-overlay activity continues. This should likely be added to #33565 rather than filed as an unrelated duplicate.

Environment

• Codex package: OpenAI.Codex 26.810.6296.0 (x64)
• Registry ProductName: Windows 10 Enterprise
• DisplayVersion: 25H2
• OS build: 10.0.26200.8893
• CPU: Intel Core Ultra 7 356H
• Logical processors: 16
• Date observed: 2026-08-15

User-visible symptoms

• Mouse pointer stutters while Codex is running.
• The issue goes away when Codex is fully closed.
• Updating Codex and restarting the PC did not permanently fix it.
• The Pet is tucked away and not visible when the CPU spike occurs.

Current measurements

An 8-second CPU-time sample while the issue was active showed:

| Codex process | Role | CPU normalized to one logical core | Share of total 16-thread CPU |
|---|---|---:|---:|
| ChatGPT.exe | Electron main process | 141.8% | 8.9% |
| ChatGPT.exe | Renderer process | 31.1% | 1.9% |
| codex.exe | App server | 0.2% | ~0% |

The main process had an 837 MB working set; the renderer had 676 MB. Immediately after reboot/fresh launch, the same main process was measured around 0.8% of one logical core. At approximately 14:20 local time, its lifetime average was about 72.3% of one logical core (7,479.8 CPU-seconds over 172.4 minutes); that lifetime number includes normal app use and is provided only as evidence that the load was sustained.

Persisted Codex state at the same time:

electron-avatar-overlay-open = false
avatar-overlay-activity-pills-visible = false

In a timestamped snapshot during the high-CPU state, the active desktop log was about 2.0 MB and contained 1,841 avatarOverlay mentions and 1,837 entries marked rendererWindowVisible=false. Avatar-overlay log activity continued while the renderer window was reported hidden. This is correlated with the CPU spike but does not by itself prove causation.

Packaged-code observations

Read-only inspection of the installed app.asar found:

1. avatarOverlayCpuOptimizations exists but defaults to false and is controlled by a remote gate.
2. The native Pet coordinator uses a 32 ms pointer polling interval.
3. Activity-stack scroll polling uses an 8 ms interval. With CPU optimizations disabled, this interval is created while the coordinator is active even when the activity stack is closed or not overflowing.
4. The Pet composition surface explicitly disables Electron background throttling.
5. Normal tuck() cleanup pauses the recovery supervisor and detaches the coordinator, which clears both intervals.
6. A separate presentation/realtime path can call compositionHost.wake() independently of the persisted Pet-open intent.
7. A hidden/prewarmed avatar renderer remains alive and subscribed to conversation events after Tuck Away.

Relevant packaged bundles in this version:

.vite/build/main-BLKctbeE.js
webview/assets/avatar-overlay-native-page-CcHeJO3-.js

Supported-setting audit

No supported permanent Pet-disable or CPU-optimization override was found in the UI, command-line flags, environment variables, or persisted user settings. The internal feature-override path is restricted to developer builds; forcing developer mode in the production package is not a safe workaround. Reduced Motion changes animation but does not prevent Pet prewarming or disable the native coordinator.

Leading root-cause hypothesis

This is an inference from the measurements and packaged code, not yet a proven minimal reproduction:

A stale presentation owner may leave the hidden Pet composition coordinator awake after a presentation path (possibly realtime voice) ends. If that is happening, the disabled avatarOverlayCpuOptimizations gate makes the 32 ms and 8 ms polling loops a plausible source of the main-process CPU load while background throttling is disabled. The packaged code proves the wake path and the expensive behavior if the coordinator is awake; available logs do not directly prove that the timers were running during the measured spike.

One realtime start/stop pair occurred in the log after the low-CPU reboot and before the later high-CPU observation. That is a correlation worth testing, not proof that realtime voice is the trigger.

Observed sequence

1. Codex launched after reboot at approximately 11:28 local time; main-process CPU was initially about 0.8% of one logical core.
2. The Pet was tucked away and persisted state remained closed.
3. A realtime session started at 11:52:51 and stopped at 11:53:11 local time.
4. At approximately 14:19, the Electron main process measured 141.8% of one logical core and mouse stutter was visible.
5. Fully quitting Codex stopped the CPU use and mouse stutter.

Candidate trigger test

1. Launch Codex Desktop and select Settings > Pets > Tuck Away.
2. Record an idle CPU baseline.
3. Start and stop a realtime voice session, then use Codex normally.
4. Check whether main-process CPU remains elevated while persisted Pet state remains closed.
5. Toggle /pet open and then closed, and check whether CPU returns to baseline and the extra renderer exits.

Voice alone has not yet reproduced the problem in a controlled test.

Expected result

Tucking away the Pet must stop/detach all native Pet polling, and its hidden renderer should either be destroyed or genuinely background-throttled. Starting and stopping another presentation mode must not reactivate it unless the Pet is actually open.

Actual result

The Pet remains configured as closed, but the hidden avatar subsystem continues processing events and Codex sustains high CPU use, causing system input stutter.

Suggested product fixes

1. Make lifecycle ownership explicit: the host is awake if and only if petOpenIntent || activePresentationOwners.
2. On realtime stop or transition completion, remove that presentation owner, reconcile state, and pause/detach only when no owner remains.
3. Run pointer and scroll polling only while the relevant surface is visible and active.
4. Destroy or background-throttle the prewarmed renderer while tucked away, and avoid unnecessary task/reasoning broadcasts to it.
5. Validate enabling avatarOverlayCpuOptimizations by default on Windows as a mitigation while the lifecycle bug is fixed.
6. Add regression tests:

• Pet state false -> realtime owner on -> realtime owner off -> coordinator paused/detached and no 8/32 ms timers.
• Hidden/prewarmed renderer unsubscribes or is background-throttled.
• Windows integration CPU returns near the fresh-launch baseline after a fixed idle window.

Candidate workaround / test

Toggle /pet once to open it, then /pet again to tuck it away. This should exercise the normal close path and may detach a stale coordinator, but it is not yet verified. Fully quitting Codex is the only confirmed workaround so far.

Privacy note for logs

The raw Codex desktop log can contain conversation text, thread identifiers, and local paths. It should be reviewed/redacted before public attachment, or shared only through the private in-app feedback flow.