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

Summary

On Windows, opening the Codex pet/avatar overlay causes severe UI stuttering. Switching tasks from the sidebar becomes laggy, and mouse dragging can become nearly unresponsive while the pet overlay is open.

Steps to reproduce

Open Codex desktop on Windows.
Enable or open the pet/avatar overlay.
Switch repeatedly between tasks in the left sidebar.
Try to drag the mouse or interact with the window.

Actual behavior

Task switching stutters or freezes.
Mouse movement/dragging becomes difficult or temporarily unresponsive.
The issue persists after restarting Codex.
It reproduces with Clash TUN disabled and Windows system proxy enabled, so it is not specific to TUN mode.

Expected behavior

The pet overlay should not affect sidebar task switching, mouse input, or desktop UI responsiveness.

Environment

Codex desktop: 26.707.12708.0
OS: Windows 11 x64
GPU: NVIDIA GeForce RTX 5060 Laptop GPU + Intel integrated graphics

Relevant diagnostics

The desktop log reports an unhandled rejection during avatarOverlay initialization:

A dynamic link library (DLL) initialization routine failed.
@worklouder/wl-device-kit/.../@serialport/bindings-cpp/build/Release/serialport.node

Windows Application Error also repeatedly records:

ChatGPT.exe
Exception code: 0xc06d007f

During the affected session, local capability refreshes were also unusually slow:

mcpServerStatus/list: 17,916 ms
plugin/list: 16,948 ms
app/list: 12,795 ms

Normal conversation data reads were much faster (typically around 270 ms), suggesting the stall is associated with overlay/native-module or capability initialization rather than loading the conversation itself.

Additional notes

The Microsoft Visual C++ runtime is installed and current. No full logs are attached because they may contain local paths or conversation metadata.

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

[Windows App] Repeated serialport.node delay-load failures cause severe UI lag #33375
Windows x64: repeated background crash (0xC06D007F) in serialport.node causes UI freezes during normal use #33518
[Windows Desktop] Every completed response causes a system-wide stall and Event 1000 from bundled serialport.node #33494
Windows startup crash: bundled @serialport/bindings-cpp delay-loads Node-API from ChatGPT.exe (0xc06d007f, ERROR_PROC_NOT_FOUND) #33525
[Windows Desktop 26.707.12708.0] Severe lag while typing and switching tasks; repeated 0xc06d007f crashes #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

Show/enable a Pet.
Keep the ChatGPT/Codex window in the foreground, particularly while a Codex turn is active.
Mouse movement becomes visibly choppy/system-wide.
Focus any other application: mouse movement immediately becomes smooth.
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

The problem started immediately after updating Codex on Aug 14, 2026.
Use Codex normally for some time with the Pet hidden.
Physical mouse movement and clicks across the entire Windows desktop become intermittently choppy/unresponsive.
CPU and GPU show no meaningful sustained load while the stalls occur.
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 Windows x64: repeated background crash (0xC06D007F) in serialport.node causes UI freezes during normal use #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 Windows: pet/avatar overlay makes task switching and mouse dragging freeze #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:

avatarOverlayCpuOptimizations exists but defaults to false and is controlled by a remote gate.
The native Pet coordinator uses a 32 ms pointer polling interval.
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.
The Pet composition surface explicitly disables Electron background throttling.
Normal tuck() cleanup pauses the recovery supervisor and detaches the coordinator, which clears both intervals.
A separate presentation/realtime path can call compositionHost.wake() independently of the persisted Pet-open intent.
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

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

Candidate trigger test

Launch Codex Desktop and select Settings > Pets > Tuck Away.
Record an idle CPU baseline.
Start and stop a realtime voice session, then use Codex normally.
Check whether main-process CPU remains elevated while persisted Pet state remains closed.
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

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

Additional Findings on Windows 11

I did some additional testing and was able to narrow down the trigger condition further.

The stutter does not seem to be caused simply by the pet being visible, window animations, DPI scaling, taskbar interaction, or the ChatGPT/Codex window being visible.

Key Trigger

The key trigger appears to be:

Pet overlay visible + ChatGPT/Codex main window becomes the active/foreground window during a window switch/minimize transition.

Reproduction

Enable/show the desktop pet.
Keep the ChatGPT/Codex main window open and visible.
Open another app, for example Notepad, in front of it.
Minimize the foreground app so that ChatGPT/Codex becomes the active window.
Move the mouse quickly during that transition.

Result

The mouse cursor briefly feels “stuck” and stops visually following the physical mouse movement.

Once the transition finishes, the cursor jumps to the position it should have reached.

Important Observations

If minimizing the foreground app makes another app active instead of ChatGPT/Codex, there is no stutter.
If ChatGPT/Codex remains visible but is not the active window, there is no stutter.
Alt + Tab away from ChatGPT/Codex does not reproduce the issue.
Showing another app with Win + number does not reproduce it.
Minimizing that app again so that ChatGPT/Codex becomes active does reproduce it.
Clicking another app's own minimize button reproduces it as well, so this does not appear to be taskbar-specific.
Built-in pets and custom pets behave the same.
Display scaling is 100%.
Disabling Windows minimize/maximize animations did not help.
ChatGPT/Codex window size does not appear to matter.
During the stutter, GPU usage briefly rises from roughly 1% to around 7%, although overall GPU load remains low.

Three-Window Test

I also tested this with three windows open:

ChatGPT/Codex
Windows Settings
Notepad

If I repeatedly minimize/restore Notepad and the next active window becomes Windows Settings, there is no stutter.

If the exact same action causes ChatGPT/Codex to become the active window, the stutter occurs.

ChatGPT/Codex can remain fully visible during both cases, so the issue does not appear to depend on whether the window is covered or uncovered.

The deciding factor appears to be which application becomes the active foreground window.

Conclusion

This suggests the trigger is specifically related to:

ChatGPT/Codex becoming the active foreground window while the pet/avatar overlay is visible.

It looks more like an interaction between main-window activation/focus + the pet/avatar overlay, possibly involving window composition or input synchronization, rather than a general GPU performance issue.

I hope this helps narrow down the reproduction path.

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

Description

Summary

Steps to reproduce

Actual behavior

Expected behavior

Environment

Relevant diagnostics

Additional notes

Activity

github-actions commented on Jul 16, 2026

ryojihido commented on Jul 16, 2026

R4cc commented on Jul 17, 2026

McLovin1UK commented on Jul 18, 2026

qyhg110q commented on Jul 18, 2026

zghoto commented on Jul 19, 2026

Jiuxiao-yunwai commented on Aug 14, 2026

Environment

Reproduction and A/B result

Performance samples while affected

Workaround

CustomAIXXX commented on Aug 14, 2026

Environment

Reproduction and behavior

Expected behavior

CustomAIXXX commented on Aug 14, 2026

Strangorth commented on Aug 14, 2026

Strangorth commented on Aug 14, 2026

CustomAIXXX commented on Aug 15, 2026

Environment

Measurements in that separated state

dennisthedude commented on Aug 15, 2026

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

Summary

Existing tracker

Environment

User-visible symptoms

Current measurements

Packaged-code observations

Supported-setting audit

Leading root-cause hypothesis

Observed sequence

Candidate trigger test

Expected result

Actual result

Suggested product fixes

Candidate workaround / test

Privacy note for logs

KAKAzere commented on Sep 19, 2026

Additional Findings on Windows 11

Key Trigger

Reproduction

Result

Important Observations

Three-Window Test

Conclusion

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions