Custom pet selected at first wake initializes a persistently undersized drag hit region on Windows

[yousizaitianqiong]

What version of the Codex App are you using?

• Codex Desktop app version: 26.721.41059
• Windows package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0

What subscription do you have?

Not relevant to this local desktop-pet reproduction.

What platform is your computer?

• Windows 11 Home China
• Version: 10.0.26200
• Build: 26200
• Architecture: x64

Summary

On Windows, the pet selected when the desktop-pet overlay is first woken
deterministically decides the drag hit-region state for the rest of that overlay
session:

Whoever owns the first wake determines the hit region inherited by every pet
switched in afterward.

• If a valid custom pet is selected when the overlay is first woken, the
  draggable/clickable hit region is undersized.
• Switching to any other custom or built-in pet while the overlay remains awake
  does not repair it.
• If a built-in pet is selected when the overlay is first woken, the hit
  region is correct.
• Switching to the same custom pet afterward keeps the correct hit region.

The visible mascot size and animation remain correct. Only the interactive
region differs.

This is deterministic and survives full Codex restarts and Windows reboots.

Steps to reproduce

Experiment A: custom pet owns the first wake

1. Fully quit Codex Desktop.
2. Launch Codex normally.
3. Make sure the pet overlay is tucked away.
4. In Settings -> Appearance -> Pets, select a valid v2 custom pet such as
   custom:yukie-head.
5. Wake the pet.
6. Try to start a drag from different visible parts of the mascot.
7. Observe that only a small portion of the visible mascot accepts the drag.
8. While the overlay remains awake, switch to a built-in pet.
9. Observe that the built-in pet inherits the same undersized hit region.
10. Switch between additional built-in and custom pets.
11. Observe that the undersized hit region remains unchanged.

Experiment B: built-in pet owns the first wake

1. Fully quit and relaunch Codex Desktop to isolate the test.
2. Make sure the pet overlay is tucked away.
3. Select a built-in pet.
4. Wake the pet.
5. Confirm that the full expected mascot area accepts dragging.
6. While the overlay remains awake, switch to custom:yukie-head.
7. Switch between additional built-in and custom pets.
8. Observe that every pet inherits the correct hit region.

These A/B results are repeatable.

Expected behavior

A valid custom pet should initialize the same mascot hit-region geometry as a
built-in pet.

The hit region should also be recomputed after the selected pet finishes
loading or changes.

Actual behavior

The first-wake path initializes one of two persistent hit-region states:

Pet selected at first wake	Initial hit region	State after switching pets
Built-in pet	Correct	Remains correct
Custom pet	Undersized	Remains undersized

Custom pet validation

The current reproduction uses a clean standard two-file package:

~/.codex/pets/yukie-head/
  pet.json
  spritesheet.webp

Validated properties:

• spriteVersionNumber: 2
• spritesheetPath: "spritesheet.webp"
• Atlas: 1536x2288
• Grid: 8x11
• Cell: 192x208
• Format: RGBA lossless WebP (VP8L)
• Transparent RGB residue: 0
• No alpha pixels touch cell boundaries
• All 16 v2 look-direction cells are populated
• Spritesheet SHA-256:
  1c92859c0cb66480f00eb44f29f6e3614d598a68b4eec700c6ed04160e1f8c8c

The same first-wake distinction has also been observed with another independent
valid v2 custom pet.

Troubleshooting already performed

• Rebuilt the custom pet from the standard package structure of recently
  maintained community v2 pets.
• Tested lossless VP8L and smaller lossy WebP encodings.
• Validated dimensions, frame occupancy, transparent RGB residue, and cell-edge
  alpha.
• Fully quit and restarted Codex repeatedly.
• Restarted Windows.
• Switched between multiple built-in and custom pets.
• Removed all launcher/runtime/database patches from the reproduction.
• Reproduced using a normal Codex launch.

None of the asset changes affect the result. Only the pet type selected at
first wake changes the hit region.

Packaged desktop-code observation

This is an inference from inspecting the packaged desktop app; the public
repository does not appear to contain this renderer source.

The current custom-avatar selection hook has a custom-only loading branch that
returns an empty selection while the individual custom-avatar query is
fetching:

if (isFetching) {
  return { selectedAvatar: null, selectedAvatarId };
}

Built-in pets are available synchronously and do not take that branch.

The custom-avatar-by-ID query also uses gcTime: 0. During a custom-first wake,
the mascot node can therefore be absent during the overlay's first layout/native
hit-region measurement, then mount only after the custom asset resolves.

The native overlay's pointer-interactivity path measures DOM hit regions and
updates the transparent Electron window's mouse-event passthrough state. The
observed A/B behavior is consistent with the initial custom loading gap
producing stale mascot bounds that are not recomputed after the custom pet
mounts.

Possible fix direction

• Do not finalize native overlay hit regions until the selected custom pet has
  loaded.
• Keep a correctly sized mascot placeholder mounted while a custom pet is
  fetching.
• Force a hit-region/native-overlay remeasurement when selectedAvatar changes
  from null to the resolved custom avatar.
• Reapply the correct Electron mouse-event passthrough state after that
  measurement.
• Recompute the mascot hit region when switching between built-in and custom
  pets.
• Add a Windows regression test covering both A/B first-wake orders.

Workaround

Wake the overlay with a built-in pet first, then switch to the custom pet. This
consistently preserves the correct drag hit region.

Related issues

• Windows pet overlay hit region desynchronizes from the visible mascot over time #34227 - hit region desynchronizes over time, but that report affects built-in
  and custom pets and is not deterministic from the first-wake pet type.
• Codex Desktop pet can start half-cropped when summoned with /pet #20828 - overlay layout may be measured before a pet is fully ready.
• Add an official setting to resize the Codex desktop pet/avatar overlay #21864 - visible pet size and clickable/draggable area should stay aligned.
• Codex Desktop silently omits a valid V2 custom pet on native Windows #33220 - current Windows v2 custom-pet loading problems.

[yousizaitianqiong]

An independent reproduction on Windows is now available in #34227:

#34227 (comment)

It reproduces the stale pointer-forwarding behavior on OpenAI.Codex 26.727.6591.0, including visible voice/collapse controls that stop accepting clicks. It also confirms that reducing every sprite frame to 85% does not change the failure.

The packaged-app observation matches the custom-first-wake trigger reported here: the custom avatar is temporarily resolved as null, the overlay becomes non-interactive, and pointer forwarding may remain stale after the avatar finishes loading.