Windows pet overlay hit region desynchronizes from the visible mascot over time

What version of the Codex App are you using?

Codex Desktop Windows package OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0.

What subscription do you have?

Not relevant to the reproduction.

What platform is your computer?

Windows NT 10.0.22631.6199, x64.

What issue are you seeing?

The draggable/clickable hit region of the desktop pet can desynchronize from the visible mascot after Codex has been running for some time.

Immediately after a Windows restart, the pet normally responds across its full visible rectangular area. Later, only the upper part of the visible mascot may accept the mouse; the center/lower part passes clicks through, so the pet cannot be dragged from most of its body.

This affects both:

• bundled/default pets;
• a valid custom v2 pet (Burny).

Switching pet assets does not fix it. Restarting Windows temporarily restores the correct hit region, but the problem eventually returns. This makes the symptom look asset-specific at first, but it is shared by all pets.

Pet width is set to the supported minimum of 80 px through avatar-overlay-mascot-width-px.

Steps to reproduce

The transition is not fully deterministic yet:

1. Start Windows and launch Codex Desktop.
2. Wake/show a desktop pet.
3. Confirm that the pet can initially be dragged from its full visible body.
4. Leave Codex running and use it normally, including pet activity/notification transitions.
5. Later, try to begin a drag from the center or lower half of the mascot.

Expected behavior

The full visible mascot area remains clickable and draggable for the lifetime of the overlay, for both bundled and custom pets.

Actual behavior

Only part of the visible mascot remains interactive while the rest of the transparent overlay passes the pointer through. A Windows restart temporarily resets the behavior.

Local technical observations

These observations come from inspecting the packaged desktop app, because the public repository does not appear to contain the desktop avatar renderer source.

Both native and non-native overlay renderers use the shared hit-region selectors:

[data-avatar-overlay-hit-region]
[data-avatar-mascot='true']

The floating-window pointer-interactivity code measures those DOM regions and dispatches avatar-overlay-pointer-interaction-changed. The Electron main process then toggles the transparent overlay window with setIgnoreMouseEvents(...).

Because this mechanism is shared by every pet, and because the visual mascot remains correct while only pointer interaction changes, this looks like a stale pointer-passthrough/native-composition state rather than sprite geometry.

The packaged app also contains an internal persisted flag named avatar-overlay-force-non-native-rendering. That suggests forcing the Chromium rendering path could be useful as a diagnostic fallback, but I have not treated that internal flag as a supported fix.

The installed custom atlas still matches its validated source hash and passes the v2 8x11 atlas validation, so no pet asset change correlates with the failure.

Possible fix direction

• Recompute and resend the interactive region after native-composition, layout, notification, display, DPI, sleep/wake, and overlay-bounds transitions.
• Ensure the native visual surface and Chromium getBoundingClientRect() values stay in the same coordinate space.
• Reapply the correct setIgnoreMouseEvents state when the overlay is re-hosted or its native surface changes.
• Add a Windows regression test covering bundled and custom pets, pet size 80, notification transitions, and long-lived overlay state.
• Consider automatically falling back to non-native rendering if native hit testing becomes inconsistent.

Related issues

• #21359 — dragging can fail after moving a pet to a secondary display.
• #21313 — the Windows pet overlay can lose correct native window behavior after wake/focus changes.
• #21864 — pet resizing should keep the visible and clickable areas aligned.