Codex Pets overlay clips/mispositions sprite and notification tray on macOS

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

• #20752
• #20828

Powered by Codex Action

Additional reproduction from Codex Desktop on macOS.

Environment observed locally:

• macOS 26.4.1 build 25E253
• Architecture: arm64
• Codex CLI: 0.128.0
• Exact Codex Desktop app version was not captured from About Codex in this thread.

Observed behavior:

• Running /pet shows a large rounded rectangular overlay/frame.
• The frame is mostly empty/dark.
• The pet sprite is very small and pinned near the bottom-right corner of the frame.
• The result looks like the overlay/window bounds are much larger than the rendered pet scene, or the sprite is being positioned/scaled relative to the wrong container.

This appears related to the clipping/mispositioning described here. It is not a custom pet asset issue in this reproduction; the visible problem is the Desktop pet overlay layout itself. There does not appear to be a documented user-facing setting in Codex config or Settings to adjust the pet overlay/frame size.

Screenshot was observed in the local Codex thread but is not attached to this GitHub comment.

Additional data point from my external-monitor setup (Codex Desktop 26.429.61741 / Build 2429, macOS, BenQ SW321C as main display, scaling set to More Space):

• Confirmed workaround: dragging the pet to the upper-left makes the sprite visible.
• - This suggests the sprite itself is loading/positioning, but clipping/bounds are wrong.
• - - New hypothesis: once the speech bubble/notification card is added, layout math pushes the sprite outside the overlay clipping box (or clamps to an incorrect viewport), leaving only a top-left fragment visible.

This was 100% reproducible in this setup.

I ran into what looks like the same class of issue on macOS.

Environment

• Codex Desktop: 26.429.61741 build 2429
• macOS: Darwin 25.4.0 arm64
• Display: external 4K display
• A custom pet was involved initially, but the notification/speech bubble was also clipped, so this did not appear to be only a pet asset problem.

Symptoms

• The pet rendered as only a tiny clipped fragment of the sprite.
• The notification/speech bubble text was also clipped.
• Switching macOS display scaling and refresh rate did not fix it.
• Restoring the original valid pet spritesheet did not fix it.
• Clearing/resetting only ~/.codex/.codex-global-state.json overlay/avatar state did not fix it.

What fixed it

A full reset of the Codex Electron/Chromium app profile fixed the issue:

mv "$HOME/Library/Application Support/Codex" \
  "$HOME/Library/Application Support/Codex.backup-pet-bug-$(date +%Y%m%d-%H%M%S)"

After restarting Codex, /pet rendered normally again.

This did not require changing ~/.codex/pets or the custom pet package.

Possible clue

Before resetting the profile, ~/Library/Application Support/Codex/Preferences contained a saved Chromium zoom entry:

{
  "partition": {
    "per_host_zoom_levels": {
      "<host-id>": {
        "-": 1.5
      }
    }
  }
}

I cannot say for sure that the zoom value was the root cause, but the full app-profile reset fixed it where display changes, pet asset changes, and overlay-state reset did not. This suggests the issue may involve stale local Electron/Chromium profile state, zoom state, or rendering/cache state in addition to overlay bounds/DPI math.

Removing partition form Preferences works for me.

Also reproducing on Windows.

Environment:

• Codex Windows App 26.506.3741.0
• Windows 11 x64
• Display scale 100%
• Built-in/default pets and custom pets are both clipped near the bottom-right.
• Restarting Codex and resetting zoom with Ctrl+0 did not help.

This looks like the same overlay-window bounds/clipping issue, but on Windows.

Additional data point from macOS, with a narrower workaround than a full app-profile reset.

Environment:

• Codex App: 26.506.31421 / build 2620
• Platform: Darwin 25.2.0 arm64 arm
• UI/text: Japanese
• Reproduced with the built-in codex pet, so this was not a custom pet atlas issue.

What I observed:

• Deleting only ~/.codex/.codex-global-state.json's electron-avatar-overlay-bounds did not fix the issue. After restart, Codex regenerated a similar clipped layout:

{
  "width": 356,
  "height": 320,
  "anchor": { "width": 80, "height": 87 },
  "mascot": { "left": 248, "top": 225, "width": 80, "height": 87 },
  "placement": "top-end"
}

• A screenshot/pixel check showed the visible pet pixels touching the overlay BrowserWindow's right and bottom edges. In other words, the pet was being drawn outside the allocated mascot area and then clipped by the transparent overlay window, rather than the sprite itself being malformed.
• Cmd+0 plus app restart did not fix it. During the broken state, ~/Library/Application Support/Codex/Preferences still contained a Chromium zoom entry:

{
  "partition": {
    "per_host_zoom_levels": {
      "<host-id>": {
        "-": 1.0
      }
    }
  }
}

What fixed it:

1. Quit Codex.
2. Remove the persisted Chromium zoom levels from the Codex Electron profile.
3. Reset the avatar overlay state so Wake Pet recreates the overlay.

tmp="$(mktemp)"
jq 'del(.partition.per_host_zoom_levels)' "$HOME/Library/Application Support/Codex/Preferences" > "$tmp" \
  && mv "$tmp" "$HOME/Library/Application Support/Codex/Preferences"

tmp="$(mktemp)"
jq 'del(."electron-avatar-overlay-bounds") | ."electron-avatar-overlay-open" = false' "$HOME/.codex/.codex-global-state.json" > "$tmp" \
  && mv "$tmp" "$HOME/.codex/.codex-global-state.json"

After restarting Codex and using Wake Pet, the pet rendered normally again. The Preferences file now has partition: {}.

Hypothesis:

The issue seems to involve persisted Electron/Chromium zoom/profile state in addition to avatar overlay bounds. The renderer appears to measure the mascot at 80x87, while the fixed overlay window/layout still clips the visual sprite near the bottom-right. This matches the previous reports that a full app-profile reset works, but in this case deleting partition.per_host_zoom_levels plus resetting the overlay bounds was enough.

Additional reproduction on the current macOS desktop build:

• Codex app: 26.715.52143 (build 5591)
• Dock: visible at the bottom

Steps

1. Drag the pet to the extreme bottom-left corner, in the horizontal area not visually occupied by the Dock.
2. Switch focus to another application/window and then return to Codex.

Actual behavior

The pet jumps upward and returns to a position immediately above the Dock. The manually selected bottom-left position is not preserved.

Expected behavior

The pet should remain where it was placed unless its actual rectangle intersects the Dock or the screen bounds.

Technical observation

Inspection of the packaged app indicates that the native overlay lays itself out against Electron's rectangular display.workArea and reclamps the persisted anchor during layout/window changes. With a bottom-aligned macOS Dock, that work area excludes a full-width horizontal strip, so the unoccupied bottom-left corner is treated as unavailable too.

This appears to be the same screen-edge positioning family described here, with focus/window changes exposing the re-clamping behavior. Enabling Dock auto-hide or moving the Dock to a side avoids the snap, but neither is an ideal permanent workaround.

No screenshot is attached because it contains unrelated application content.