Codex Desktop pet overlay appears to increase idle GPU/renderer CPU on macOS

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

• #20435
• #19942
• #19253
• #19916

Powered by Codex Action

I reviewed the suggested duplicates. They look related to the same broad renderer/compositor family, but I don’t think this is a direct duplicate.

This report is specifically about the new Codex pet overlay: with the pet visible, GPU/helper load is higher; after tucking the pet away, app-server drops to 0%, one renderer disappears, and GPU helper usage drops. None of the suggested duplicates mention /hatch, the pet overlay, or pet visible vs tucked-away measurements.

Closest related issue seems to be #16857, since that also points to a small animation keeping Chromium’s compositor active.

Retested on Codex Desktop 26.506.31421 on macOS 26.4.1.

In a local sample with the pet overlay closed:

• GPU helper: ~18.7-23.9% CPU
• main renderer: ~14.7-21.9%
• app-server: ~0%

In a local sample with the pet overlay open:

• GPU helper: ~29.8-39.3% CPU
• main renderer: ~11.4-15.6%
• an additional renderer appeared at ~8.0-12.9%

This was not a perfectly controlled benchmark, but it suggests the broader idle renderer/GPU load is still present and that the pet overlay may add extra overhead on top.

Hm, I'm not sure whether it's really related to this specific issue, but it seems that when the pet is "awake", going into different threads or even just the agent working, causes AWFUL lags: as the mouse is getting frozen (audio is still hearable tho), along with extremely lowered performance of the whole PC basically.

I'm on Windows PC, using 26.513.40821 desktop app. And it's not like my hardware can't handle heavy load - I'm currently running RX5700XT paired with Ryzen 7 5800X...

Having the pet visible basically renders the app (and the pc, but most lags happen in the app) barely usable. Disabling the pet completely makes the problem go away. I'm not really sure whether it's a regression as I haven't really used pets that much, but I did check them out once before and I don't remember it being so broken...

If that needs a separate issue, please let me know or transfer this comment as an issue

I hit a more specific variant of this on macOS where the pet itself is less of a problem than the streaming text/status shown inside the pet overlay.

Environment:

• Codex Desktop: 26.527.60818
• macOS: 26.5 (25F71)
• Machine: Apple Silicon / M1 Pro

What I observed:

When the pet / avatar overlay was visible while Codex was actively processing and updating text in the pet overlay, macOS desktop compositing became very expensive:

WindowServer              ~40-50% CPU
Codex (Renderer)          spikes around ~85-88% CPU
Codex GPU/Service process ~30-46% CPU

Memory pressure was normal, so this did not look like RAM pressure or local command execution. The process pattern pointed at rendering/compositing.

After disabling/closing the pet overlay and waiting a short period, repeated sampling showed WindowServer and the Codex renderer falling back down:

WindowServer samples after closing pet:
13.2%, 16.3%, 10.6%, 4.9%, 2.8-3.2%

Codex (Renderer) after closing pet:
roughly ~4.8-10.2% in the follow-up samples, then no longer near the top CPU users

System CPU idle:
roughly ~89-92%

This makes the pet overlay look like the trigger. My guess is that token-by-token or high-frequency text/status updates in the transparent always-on-top avatar-overlay window are causing repeated layout/paint/compositing work. The stack sample also showed QuartzCore/CALayer/IOSurface/CA transaction activity, consistent with this being a compositing path issue.

Possible mitigations:

• Throttle/debounce pet overlay text updates, e.g. update at most every 300-500 ms instead of every streaming delta.
• Update only on sentence/paragraph boundaries.
• Keep the pet animation visible but disable streaming text/status in the overlay.
• Add a setting like "pet animation on, streaming status bubble off".
• Avoid repainting the transparent overlay when only offscreen/incremental text state changes.

This is likely related to #16857 and the broader WindowServer/GPU reports such as #24185 and #23026, but this specific repro points to the pet overlay's streaming text/status updates as the high-frequency repaint trigger.

I can reproduce the Windows system-lag variant described above, and a controlled A/B test strongly isolates the pet/avatar overlay.

Environment

• Codex Desktop bundled version: 26.707.31123
• Windows package version: 26.707.3563.0
• Platform: Windows x64

Symptom

With the main Codex window hidden or minimized but the pet/avatar overlay still visible, mouse and keyboard input pause for roughly 1–2 seconds several times per minute. Fully quitting Codex stops the pauses.

Controlled A/B measurements

Before closing the overlay:

• The Electron GPU process continuously used roughly 30–73% of one logical CPU core.
• Codex occasionally spiked to about one full CPU core.
• Reported hardware GPU-engine utilization stayed below 1%.
• Total system CPU remained relatively low, while DPC, interrupt, disk-queue, and paging counters were normal.

After closing only the pet/avatar overlay:

• Codex remained running.
• During the next 20-second idle sample, the Electron GPU process stayed at 0% CPU and total Codex CPU averaged 0.4%.
• During a later 45-second sample while diagnostics were active, the GPU process averaged 7.5% CPU, versus the sustained 30–73% range with the overlay open.
• The overlay stayed closed throughout the follow-up test.

The Computer Use plugin was disabled during the final A/B test. Its idle native pipe remained present before and after closing the overlay, while the rendering load disappeared when the overlay closed, so Computer Use infrastructure does not appear to be the primary trigger.

Reproduction

1. Open Codex Desktop on Windows.
2. Open/wake the pet avatar overlay.
3. Hide or minimize the main Codex window, leaving the avatar overlay visible.
4. Use the mouse and keyboard in other applications for several minutes.
5. Observe intermittent input freezes and sustained CPU use by Codex's Electron GPU process.
6. Close only the avatar overlay and repeat the measurements.

Expected behavior

A decorative always-on-top overlay should suspend or substantially throttle rendering while idle and should not cause system-wide input freezes.

The measurements suggest a persistent Chromium compositor/render loop in the transparent avatar window. Throttling animation and streaming-status updates when idle may help. No raw logs are attached because they can contain local paths, account data, and thread contents.

I can independently reproduce the Windows system/input-lag variant on a different current build and an NVIDIA GPU.

Environment

• Windows MSIX package: OpenAI.Codex 26.707.12708.0
• Bundled app-server reported by the desktop log: 0.144.5
• OS: Windows 11 Pro 10.0.26200, x64
• GPU: NVIDIA GeForce RTX 4070 SUPER
• GPU driver: 32.0.16.1074
• Windows animations: enabled
• Built-in pet; no custom pet files are installed

Deterministic A/B reproduction

1. Tuck away the pet, fully quit Codex, and restart it.
2. Mouse movement and chat switching are smooth again.
3. Wake the pet.
4. Mouse movement immediately starts stuttering, and switching chats becomes visibly janky.
5. Tuck away the pet and fully restart Codex.
6. The stutter disappears.
7. Wake the pet again.
8. The stutter returns.

This A/B was reproduced twice on the same machine and app configuration. A full restart after tucking the pet away is currently the reliable workaround.

Sanitized desktop-log evidence

In a session that was smooth after restarting with the pet tucked away, waking the pet created a separate avatar-overlay window:

window main frame finished load appearance=avatarOverlay startupElapsedMs=36
window ready-to-show appearance=avatarOverlay startupElapsedMs=40
[startup][renderer] app routes mounted after 3295ms rendererWindowAppearance=avatarOverlay

Immediately afterward, the overlay renderer joined three active conversations as a follower:

thread_stream_role_changed rendererWindowAppearance=avatarOverlay role=follower
thread_stream_role_changed rendererWindowAppearance=avatarOverlay role=follower
thread_stream_role_changed rendererWindowAppearance=avatarOverlay role=follower

The overlay also performed its own app/bootstrap work and emitted errors, including:

Request failed method=fs/readFile ... os error 3 ... rendererWindowAppearance=avatarOverlay
Request failed method=remoteControl/status/read ... rendererWindowAppearance=avatarOverlay

All account, host, thread, turn, and request identifiers have been removed. Raw logs are not attached because they contain local paths and conversation metadata.

Interpretation

This suggests the transparent always-on-top pet window is not only rendering the sprite. It mounts another app renderer and subscribes to active thread streams, adding renderer/compositor and event-processing work. The same machine switches chats normally after the pet is tucked away and Codex is restarted, so generic chat hydration alone does not explain the symptom.

Expected behavior

The pet overlay should not degrade OS pointer responsiveness or chat-switch performance. Its animation and status updates should be throttled, and the overlay should avoid mounting/subscribing to more application state than it needs.

Related:

• #30428 — Windows chat-switch/UI/mouse stutter
• This issue already contains similar Windows and macOS overlay/compositor reports; this comment adds an independent Windows 11 + NVIDIA reproduction on 26.707.12708.0.

To add to that, I'll mention that it still keeps happening since I've first posted here, but I believe it's even worse now. The mouse can stutter so often, which causes so much frustration that having a pet overlay is basically a no go for me... And I really started to like both Codex and Null:d

I can reproduce this on Windows as well.

Environment

• ChatGPT Desktop 26.715.21425
• Windows 11 Pro, Version 25H2 (OS build 26200.8875)
• Windows Feature Experience Pack 1000.26100.334.0
• Windows 64-bit, x64-based system
• Intel Core i9-13900KF
• 128 GB RAM
• NVIDIA GeForce RTX 4090, 24 GB

After a fresh restart of the ChatGPT app, switching between threads is completely smooth. As soon as I enable Show Pet, switching between threads causes brief but noticeable mouse/UI stutters. Similar stutters can also occur while an agent is actively processing.

Hiding the pet does not resolve the issue once it has been enabled. Fully quitting and restarting the ChatGPT app clears the stuttering until Show Pet is enabled again.

Other applications remain smooth, including Discord, web browsers, and File Explorer. Task Manager does not show any significant CPU, GPU, disk, memory, or system-wide resource spikes during the stutters.

I also submitted an in-app bug report with reference:
no-active-thread-019f7095-45a7-7a00-a96e-6f8f8bd99787