[Windows][Pets] 150% display scaling makes the floating pet non-interactive

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

26.831.2377.0

What subscription do you have?

Team

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On a 3840x2160 display at 150% scaling, the floating pet is visibly rendered but its interactive input region does not overlap the sprite. Mouse input passes through to the window underneath, so clicking cannot bring the Codex app forward, dragging does not work, and the pet's voice controls cannot be used.

This was verified with native Win32 hit testing, not inferred from appearance:

• The overlay window was topmost, visible, enabled, and initially did not have WS_EX_TRANSPARENT.
• A WindowFromPoint scan across the entire physical overlay rectangle (3165,0 to 3840,2160) produced zero hits on the overlay.
• Single-clicking, double-clicking, and right-clicking the pet's head, body, and feet all reached the underlying window. Right-clicking opened the desktop context menu.
• The sprite appeared to render at approximately 29x48 logical pixels while the expected/registering region was 116x141, indicating inconsistent scale-factor handling between rendering and hit testing.
• In another reproduction, moving the pointer over the pet caused the overlay to acquire WS_EX_TRANSPARENT and remain fully click-through until the app was restarted, apparently because the renderer concluded that the pointer was outside the pet.

What steps can reproduce the bug?

1. Use Windows with a 3840x2160 display configured to 150% scaling.
2. Launch Codex App 26.831.2377.0.
3. Wake a floating pet and position it normally near the right edge of the display.
4. Try to click the pet to bring Codex forward.
5. Try to drag the pet.
6. Try to use the voice button shown with the pet.
7. Optionally inspect the overlay with WindowFromPoint; the visible pet area resolves to the underlying application instead of the Codex overlay.
8. Move the pointer across the pet and observe that the overlay may become permanently click-through until restart.

Resetting electron-avatar-overlay-bounds and rebuilding clean position state did not resolve the issue. The state file contains no DPI or scale-factor setting that can compensate for the mismatch.

What is the expected behavior?

The OS input region should track the visibly rendered pet at every Windows display scale. Clicking the pet should return focus to Codex, dragging should move it, and visible pet controls should receive input. Pointer movement must not leave the overlay permanently click-through.

Additional information

The likely defect is in the coordinate conversion between CSS layout and the native input shape. The renderer derives hit rectangles from getBoundingClientRect(), while the native overlay applies those rectangles through setInputShape. At 150% scaling, the CSS/DIP coordinates appear to be passed to native hit testing without the required conversion, or converted more than once. This root-cause explanation is an inference; the zero-hit scan and click-through behavior above are directly measured.

No session transcript or logs are attached because they may contain unrelated private data. The reproduction is independent of conversation content.

Start with the renderer code that derives hit rectangles from getBoundingClientRect(), then trace how the native overlay applies them through setInputShape. Reproduce the issue at 150% Windows scaling and compare the visible sprite bounds with the native input region. Done means the input region tracks the rendered pet, clicks and dragging work, controls receive input, and pointer movement does not leave the overlay click-through.