[Bug][macOS] Pet stops surfacing progress/completion after sustained use; dismissing it can hide the only completion signal until restart
What version of the Codex App are you using?
Current Codex Desktop build on macOS as of 2026-08-26. I have not re-captured the exact About version for this occurrence yet. A recent local capture from 2026-08-02 showed Codex runtime 0.146.0-alpha.3.1.
What platform is your computer?
macOS 26.6.1 (25G76), Apple Silicon.
What issue are you seeing?
After using Codex Desktop intensively for a while, the Pet/avatar overlay can enter a degraded state where it is still visible, but stops reliably surfacing the speech-bubble progress/status messages that normally tell me what the active task is doing.
The exact threshold is unclear. It seems more likely after sustained/high-volume use and many fast task cycles, rather than immediately after launch.
Once this happens:
- the Pet may simply remain visible without saying what Codex is currently doing;
- I can no longer rely on the Pet to tell whether a task is still running or has already finished;
- a task may complete while I am working elsewhere, but I do not notice unless I reopen/focus the main Codex UI and visually inspect the thread;
- the Pet can briefly enter the green/completed state, but the completion signal is not delivered persistently/reliably;
- if I dismiss/hide the Pet after that completion state, the completed state/notification does not come back;
- once the overlay is in this degraded state, fully restarting Codex is the only reliable recovery I have found.
This matters especially in a fast task workflow. I often start another task as soon as the previous one finishes. If the Pet stops reporting progress/completion, I can unknowingly leave already-finished work sitting for tens of minutes because there is no reliable out-of-window signal that Codex is done.
Steps to reproduce
The transition into the bad state is intermittent, but the observed pattern is:
- Launch Codex Desktop with the Pet/avatar overlay enabled.
- Run many tasks in succession and keep using Codex for an extended period.
- While working in another app/window, rely on the Pet speech bubbles to show current task progress.
- At some point, observe that the Pet remains present but stops showing normal progress/status bubbles for active work.
- Let a task finish without reopening the main Codex window.
- Observe that completion is easy to miss; the Pet may only briefly become green or otherwise fail to surface a persistent completion report.
- Dismiss/hide the Pet once.
- Observe that the completed/ready signal does not reappear.
- Continue using Codex: the Pet remains unreliable until the app is fully restarted.
Expected behavior
The Pet should remain a reliable out-of-window task-status surface for the lifetime of the app session.
In particular:
- while a task is running, it should continue to surface current progress/status rather than silently remaining on screen;
- when a task completes, the completion/ready state should be delivered reliably even if the main Codex window is not focused;
- dismissing/hiding the Pet should not permanently consume the only completion signal;
- an unread completed task should remain discoverable as ready/completed until the user acknowledges it;
- the overlay should recover/reconcile from authoritative thread state without requiring a full app restart.
Actual behavior
After sustained use, the overlay can become effectively silent: the Pet is still there, but progress bubbles stop appearing and task completion can be missed. Dismissing it can remove the only visible completion cue, and restarting Codex is required to restore reliable behavior.
Impact
This is not only cosmetic. It breaks the Pet's value as a lightweight task monitor.
For high-frequency agent workflows, completion-delivery latency directly becomes wasted wall-clock time: the task may already be finished, but the user has no reliable signal unless they reopen Codex and inspect the thread manually.
Related issues
Related, but not identical:
- #24302 — Pet tray omits active threads and shows inconsistent thread status.
- #35447 — feature request for a richer actionable Pet task strip.
- #39178 — Windows report involving
avatarOverlayownership and stale completed-thread UI state.
This report is narrower: the Pet/avatar overlay itself appears to degrade after sustained use and stops reliably surfacing progress/completion until restart, even though the underlying task can complete normally.
I can provide a screenshot/video of the silent Pet state and the exact current About version on the next occurrence if useful.
2 Comments
Additional clarification from the current occurrence: there appear to be at least two degraded states, not just one.
I am not claiming the transport/render process is definitively dead; this is the user-visible boundary. The important distinction is that the second state is stronger than a lost completion notification: the Pet surface itself can stop respawning/reconnecting.
This also explains why the workaround is inconsistent: dismiss/reopen may recover the first state, but once the second state occurs, only a full Codex restart has reliably restored the Pet so far.
Additional observation that may narrow the trigger:
The failure appears to correlate with an in-place Codex Desktop UI update rather than simple long-session duration.
On this occurrence, the Pet/avatar overlay behavior changed during the same session. Before the failure, the Pet UI did not include the new voice/call control below the avatar. After the failure/recovery cycle, the Pet reappeared with that new control visible. I also observed the main Codex UI changing around the same update window.
This suggests a stronger hypothesis than "sustained use eventually breaks the Pet":
So the long runtime may only increase the chance of crossing an update boundary; it may not be the root cause by itself.
I do not have enough evidence yet to claim causation, but the correlation is strong enough that I would check hot-update / renderer rehydration / avatarOverlay state reconciliation across app-version or feature-surface changes.
I have a screenshot from this occurrence showing the Pet after recovery with the newly visible voice/call control. I can attach it if useful.