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

I can reproduce this on a current macOS build with a controlled OFF -> ON -> OFF test.

Environment

• Codex Desktop: 26.727.51351 (build 6119)
• Bundled CLI: codex-cli 0.146.0-alpha.9.2
• macOS: 27.0 (26A5388g)
• Hardware: MacBook Pro with M5 Max and 128 GB RAM

System memory pressure was healthy during the test: approximately 92% headroom, no swap I/O, and no thermal or CPU power warning.

Reproduction

1. Tuck away the Codex pet and record process samples.
2. Show the pet, wait approximately 10 seconds, and record five samples at two-second intervals.
3. Tuck away the pet again and record another five samples.

Results

| Metric | Pet off | Pet on | Pet off again |
| --- | ---: | ---: | ---: |
| WindowServer CPU | 77.9% baseline | 109.9% average | 77.9% average |
| Codex GPU helper CPU | 16.6% baseline | 21.5% average | 17.2% average |
| Codex renderer processes | 6 | 13 | 6 |
| Combined renderer RSS | ~2,479 MB | ~5,027 MB | ~2,479 MB |

WindowServer samples with the pet visible were 95.3%, 126.7%, 123.0%, 102.3%, and 102.3%. After tucking it away they were 76.2%, 89.1%, 77.4%, 76.1%, and 70.5%.

Showing the pet created seven additional Codex (Renderer) processes and increased combined renderer RSS by approximately 2.55 GB. Tucking it away returned the renderer count and aggregate RSS to the prior baseline.

One newly created renderer remained alive at approximately 104 MB after the pet was tucked away, although another renderer exited, so the total count still returned to six. One cycle is not enough to conclude whether this is intentional reuse or a lifecycle leak.

The matching WindowServer, GPU-helper, renderer-count, and RSS changes strongly point to the transparent pet/avatar overlay and macOS compositing path rather than CPU, memory, swap, or thermal pressure.

A useful mitigation may be to suspend or heavily throttle the overlay animation/compositing loop while idle or while another application is fullscreen, in addition to reducing the amount of app state mounted by the avatar-overlay renderer.

Additional macOS datapoint from Codex Desktop 26.730.61639 (build 6234), observed 2026-08-05.

User-visible symptom: the desktop UI has intermittently frozen during concurrent/long-running Code Mode work.

Read-only sampling while the pet/avatar overlay was present:

• GPU helper: about 21% CPU
• main renderer: about 8% CPU at the first sample
• all ChatGPT/Codex-family processes combined: about 40% CPU and 2.1 GiB RSS
• system swap in use was about 9.36 GiB of 10 GiB

Current-session desktop logs repeatedly referenced rendererWindowAppearance=avatarOverlay and contained:

• 31 × ResizeObserver loop completed with undelivered notifications
• 81 × events for an unknown conversation
• 23 × Conversation state not found

Those event-state errors were often emitted to both the primary renderer and avatar overlay. There was no current-session renderer/GPU crash, OOM, DB-lock/corruption, auth failure, or network-timeout signature, and Codex Doctor reported healthy local databases and connectivity.

An older Codex app bundle with the same bundle identifier was installed but was not running. A previous app-server process had also survived as PPID 1 with child node_repl processes, so resource/process-lifecycle pressure may be additive. This is an inference, not a proven root cause.

This seems consistent with the pet overlay adding sustained renderer/GPU work, and possibly amplifying UI event/resize churn under multi-session load. Tucking the pet away and restarting after active tasks finish is the safest workaround being tested. No private prompt content or raw logs are attached.