[macOS][Pets] Show pet cannot recover invisible overlay; switching pets restores a frozen, non-interactive sprite #45623

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT/Codex desktop app 26.903.71938, build 8576, bundle ID com.openai.codex. Version read from the installed app bundle during troubleshooting.

What subscription do you have?

Not provided.

What platform is your computer?

macOS 26.3.1 (25D2128), Apple Silicon.
uname -mprs: Darwin 25.3.0 arm64 arm.

Two displays:

• Built-in: logical 1512 × 982, 120 Hz.
• External U27P10: logical 2560 × 1440, 60 Hz; arranged above the built-in display.
• Both displays were online during the failure investigation.

A local custom V2 pet is selected (spriteVersionNumber: 2, PNG atlas 1536 × 2288). Built-in pets have not been systematically tested for comparison.

What issue are you seeing?

The desktop pet repeatedly becomes invisible and does not return on its own. “Show pet” does not recover it. Switching to another pet and back can restore the sprite, but the restored pet can remain completely motionless and unresponsive to mouse interaction/dragging. It later disappeared again.

The main app remained usable for the troubleshooting session.

Related: #43404 describes macOS multi-display pet invisibility. This report focuses on the failed recovery path and loss of interaction after switching pets, with observations from a newer build. The original disappearance may share that issue's cause, but this has not been established.

What steps can reproduce the bug?

Observed sequence, not yet a deterministic reproducer:

1. Enable a local custom pet and use Codex with the two-display arrangement above.
2. Continue normal use, including switching between displays. The user suspects display switching as the trigger, but no exact triggering sequence has been isolated.
3. The pet becomes invisible and stays missing.
4. Invoke “Show pet”: it remains missing.
5. Select a different pet, then select the original pet again.
6. The sprite can reappear but remain static and non-interactive.
7. The pet can disappear again later.

What is the expected behavior?

• The pet remains visible and interactive on a valid display.
• Explicitly showing a missing pet recovers a usable overlay, even when the app's logical open state is already true.
• Switching pets does not leave a visible but unusable sprite.
• Recovery should not require restarting the entire desktop app and interrupting other work.

Additional information

Fault-time observations

On 2026-09-15 around 13:54 China Standard Time (UTC+8), the user reported another disappearance. A read-only snapshot captured at 2026-09-15T05:54:13.591Z showed:

• Persisted electron-avatar-overlay-open = true.
• The latest avatar-overlay log record at 05:54:11.538Z still had rendererWindowAppearance=avatarOverlay and rendererWindowVisible=true.
• The persisted pet anchor was (1091, 33) on the built-in display, whose saved bounds were (0, 0, 1512, 982).

These are saved-state/log observations, not proof that the pet pixels were visible or that the live native window bounds and input region were correct.

An earlier display-change log entry at 02:08:41.006Z said:
[avatar-overlay] Discarding pending pet move for display change.
That entry does not establish the trigger for the later disappearance.

Checks already performed

• The local PNG passed chunk CRC and decompression checks.
• Every used standard-animation frame, the neutral frame, and all 16 directional frames contained visible pixels; animation frames were not identical copies.
• Network requests from the app logged ERR_INSUFFICIENT_RESOURCES, but no causal connection to the local pet image was established.
• No renderer-exit or GPU-crash signature was found in the inspected log intervals. This is bounded negative evidence, not proof that rendering was healthy.

Recovery code observation / investigation lead

Read-only inspection of this build's shipped JavaScript found that the overlay manager's wake() method returns early when the pet-open intent is true, the existing window has not been destroyed, and shouldPresentWindow() is true. That branch republishes the hosted content relationship but does not re-show or recreate the overlay. shouldPresentWindow() is based on presentation/open intent, not successful pixel presentation or pointer interaction.

This is a plausible reason an explicit show action cannot repair a logically open but unusable overlay. The branch taken during the reported click was not instrumented, so this is not a confirmed root cause.

Please consider a supported overlay-only reset/recreation path and diagnostics covering actual window bounds/Space assignment, renderer content, input shape, mouse passthrough, and rendering state when the pet is missing or non-interactive. No client patch or proposed fix has been applied or validated.

Only sanitized technical observations are included; no full logs, conversation contents, account identifiers, or personal filesystem paths are attached.