Codex Desktop pet can start half-cropped when summoned with /pet

What version of the Codex App are you using?

Codex Desktop 26.429.30905, build 2345.

What platform is your computer?

macOS 26.3 build 25D125, Apple Silicon / arm64.

What issue are you seeing?

When I summon the desktop pet with /pet, some pets can start rendered as trimmed/cropped, as if only about half of the pet image is visible. The pet asset itself appears to be valid; the bad state looks like the avatar overlay or sprite frame is clipping the rendered cell at initial display time.

This is visible on my machine whenever I summon /pet with an affected pet.

What steps can reproduce the bug?

1. Open Codex Desktop.
2. Select an affected pet in Settings > Appearance > Pets, or use the currently selected affected pet.
3. In a Codex thread, run /pet to wake/show the desktop pet.
4. Observe the initial desktop pet render.

Expected behavior

The full pet sprite should be visible when /pet summons the overlay. The initial frame should fit within the overlay window without clipping, regardless of which built-in or valid custom pet is selected.

Actual behavior

The pet can initially appear trimmed/cropped, with only part of the image visible.

Related issues searched

I searched existing openai/codex issues on 2026-05-02. Close but not exact matches:

• openai/codex#20752 reports pet/avatar overlay and notification tray clipping on macOS Screen Sharing. This may share the same overlay clipping root, but this report is specifically about the pet starting half-cropped when summoned with /pet.
• openai/codex#20808 reports custom pet scaling artifacts from forced sprite resampling. That is related to renderer sizing, but it is about aliasing/resampling rather than the sprite being clipped.
• openai/codex#20730 reports custom pet path loading in WSL, not this render issue.

Local evidence from the packaged app

The issue does not look like a malformed atlas dimension problem:

• The installed custom pet on this machine, ~/.codex/pets/hyrax/spritesheet.webp, is 1536x1872.
• The packaged built-in spritesheets are also 1536x1872:
• bsod-spritesheet-v4-BRrRVy1T.webp
• codex-spritesheet-v4-Bl6P89d_.webp
• dewey-spritesheet-v4-gAYk_M9g.webp
• fireball-spritesheet-v4-BtU8R9Qp.webp
• null-signal-spritesheet-v4-CCoTR-8t.webp
• rocky-spritesheet-v4-3RlTi26B.webp
• seedy-spritesheet-v4-CdlE_fn9.webp
• stacky-spritesheet-v4-CaUJd4fY.webp

Those dimensions match the renderer contract of an 8 x 9 atlas with 192x208 cells.

The packaged renderer appears to crop each frame through CSS background positioning rather than by drawing an <img>:

• webview/assets/codex-avatar-D82knaKt.css sets the avatar root to aspect-ratio: 192/208, width: 7.04rem, background-size: 800% 900%, and image-rendering: pixelated.
• webview/assets/codex-avatar-BpKnWN_W.js maps animation frames by row/column and sets backgroundPosition from columnIndex / 7 * 100% and rowIndex / 8 * 100%.
• webview/assets/avatar-overlay-page-Dj9Zinq_.js renders the avatar inside a full-screen transparent overlay container with overflow-hidden.

Inference: if the overlay window bounds, CSS root size, or first background-position/layout pass is stale or computed before the sprite/layout is fully ready, a valid 192x208 frame can be clipped at summon time. This would explain why valid spritesheets can still start visually trimmed.

Additional information

No screenshot is attached from this automation run, but the issue is visible on the reporter's machine when /pet is summoned.