[Windows][Pets] Built-in and custom floating pets become click-through and cannot be dragged

[Lucency09]

Environment

• ChatGPT/Codex desktop app: 26.825.5331.0 x64
• Also reproduced on: 26.825.4187.0
• Platform: Windows x64
• Pets tested:
  • Official built-in pet: Codey
  • Custom pet: Remiel (configured width: 224 px)

Description

The floating pet becomes click-through and cannot be clicked or dragged. Pointer input is delivered to the desktop or application underneath the pet.

The issue affects both the official built-in Codey pet and the custom Remiel pet. Switching pets does not resolve it, so it does not appear to be caused by custom pet artwork or packaging.

The overlay can also display layout artifacts. In the attached screenshots, the controls are clipped and a visible purple rectangular boundary appears beside/below the built-in pet.

Steps to reproduce

1. Wake the floating pet.
2. Select the official built-in Codey pet.
3. Move the pointer over the mascot and press-drag.
4. Observe that the click is handled by the desktop or application underneath instead of starting a drag.
5. Switch to the custom Remiel pet and repeat.
6. Observe the same click-through behavior.

Expected behavior

The mascot hit region should receive pointer input, and both built-in and custom pets should remain draggable.

Actual behavior

Pointer input passes through the pet overlay to the underlying desktop or application. The pet cannot be dragged.

Diagnostics

The pet overlay retained the Windows WS_EX_TRANSPARENT extended style:

• Broken state: ExStyle 0x2800A8
• Temporarily working state: ExStyle 0x280088
• In a 15-second diagnostic run, 150/150 samples remained transparent while the cursor was inside the overlay.

Clearing only WS_EX_TRANSPARENT temporarily restored dragging. The application later enabled the flag again, and dragging stopped again.

Suspected cause

This appears to be a mismatch between the avatar overlay's internal pointer-interactivity state and the actual Windows extended window style.

The input-shape path appears to mark mousePassthroughMode as disabled after setInputShape() succeeds. If WS_EX_TRANSPARENT remains enabled at the Windows level, later calls can skip setIgnoreMouseEvents(false) because the internal state already says mouse passthrough is disabled.

It may be necessary for applyInputShape() to call setIgnoreMouseEvents(false) unconditionally before applying the input shape, or to verify the actual Windows style before returning.

Troubleshooting already attempted

• Fully restarted the desktop app.
• Reproduced across app versions 26.825.4187.0 and 26.825.5331.0.
• Switched between the official built-in Codey pet and the custom Remiel pet.
• Verified that clearing only WS_EX_TRANSPARENT temporarily restores dragging.

Attachments

1. CodexPetBug_01_Custom_Remiel_ClickThrough.png

2. CodexPetBug_02_BuiltIn_Codey_ClickThrough.png

[github-actions]

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

• Windows: Pet overlay reacts to hover but ignores clicks, dragging, and voice controls #41506
• Windows floating pet remains click-through and cannot be dragged #41465
• Windows pet overlay loses its hit region after the first drag #41501
• Pet can only be repositioned once after refreshing or reselecting it #41306

Powered by Codex Action

[liangzhe2026]

Additional independent reproduction on Windows:

• Codex Desktop: 26.825.5331.0 x64 (the app updated from 26.825.4187.0 during investigation)
• Display: 1920×1080
• The built-in Codey mascot remains visible, but clicks and drag attempts are delivered to the desktop underneath.

OS-level observations from the broken state:

• WindowFromPoint at several coordinates inside the visibly rendered mascot returned Explorer's desktop SysListView32 / FolderView, not the avatar-overlay window.
• Sending WM_NCHITTEST directly to the overlay for the same points returned HTCLIENT.
• In this reproduction, the overlay extended style was 0x80088; WS_EX_TRANSPARENT was not set.

This may indicate a second failure mode in the native setInputShape() path: the visible mascot can be excluded from the actual Windows input shape even when the ordinary WS_EX_TRANSPARENT flag is clear. It would be useful for the fix/regression test to verify both the extended style and the effective native input shape after pointer regions are recomputed.

[HB-JAZZ]

Additional reproduction on Windows:

• ChatGPT/Codex desktop app version: 26.825.41651
• Release date shown in About: 2026-08-29

Observed behavior:

1. The floating pet is visible but normally cannot be clicked or dragged; pointer input passes through to the window/desktop underneath.
2. Refreshing/reloading the app temporarily restores pet dragging.
3. Immediately after a refresh, the pet can be dragged once.
4. After that first successful drag, the pet becomes click-through again and cannot be dragged.
5. Refreshing again restores exactly one successful drag, so the behavior is repeatable.

This suggests the overlay starts in a correct pointer-interactive state after refresh, then switches back into an incorrect mouse-passthrough state after the first drag/interactivity transition.

Current workaround is to refresh and use the single drag opportunity to move the pet out of the way, or disable the pet.

[qcy007]

Additional independent reproduction on Windows:

• OS: Windows 11 Pro, version 10.0.26200 (build 26200)
• Codex Desktop package: 26.825.5331.0 x64
• Package version was verified locally with Get-AppxPackage OpenAI.Codex
• The problem began immediately after updating on 2026-08-30

Observed behavior:

• The floating pet remains visible, but clicking it has no effect.
• Pressing and dragging does not start a drag, so the pet cannot be repositioned.
• This matches the non-interactive/click-through behavior described in this issue.

No local patch or modification has been applied to the Codex package.

[zj411017-rgb]

I can reproduce a closely related Windows issue with a custom v2 pet. The pet stays visible, but clicks and drag gestures pass to the window underneath; hide → show reproduces it immediately.

In a native trace, clicks made on the visible pet did not intersect the overlay window’s physical bounds. Hide/show destroyed and recreated the overlay/render host, after which the input path diverged again. Clearing WS_EX_TRANSPARENT or resetting region/bounds was not a reliable fix.

This appears to be a host-side synchronization issue between the displayed pet surface, display placement, and the Chromium/Owl input region, especially after hide/show on a multi-display Windows setup.

[panchinpeng]

Still reproducible in a newer version.

Environment:

• ChatGPT/Codex desktop app: 26.825.6671.0 x64
• Platform: Windows x64
• Pet tested: built-in pet

Behavior:
The floating pet is visible and animated, but it cannot be clicked or dragged. Mouse input appears to pass through the pet overlay to the window or desktop underneath.

This matches the WS_EX_TRANSPARENT / pointer-interactivity symptoms described in this issue. The problem is therefore still present in 26.825.6671.0, which is newer than the previously reported 26.825.5331.0 build.

Please let me know if additional diagnostics or logs from this version would be helpful.

[asdesign2026]

Confirmed independently, including with a working external proof-of-concept.

Environment

• Codex Microsoft Store package: 26.825.6671.0
• Architecture: ARM64
• Windows build: 26200.9168
• Display DPI: 192 / 200% scaling
• Pet overlay class: Chrome_WidgetWin_1
• Observed overlay bounds: 1928,0 952×1800
• Affects both mouse and touchscreen input
• Rendering and hover behaviour continue normally

Controlled test results

1. The pet was visible, but pointer-down and drag events passed through it.

2. The overlay had WS_EX_TRANSPARENT.

3. Clearing WS_EX_TRANSPARENT alone did not restore interaction in this state.

4. A small helper-owned input surface placed over the visible pet, combined with:

   • clearing WS_EX_TRANSPARENT immediately before input, and
   • forwarding WM_LBUTTONDOWN, WM_MOUSEMOVE, and WM_LBUTTONUP to the pet overlay

   reliably restored clicking and dragging.

5. The helper’s input surface could follow the pet after the drag completed.

6. No pet asset, Codex package, app data, or renderer files were modified.

This demonstrates that the pet renderer and drag behaviour are still functional. The failure is in the Windows native pointer-routing/input-region state, not the pet asset or mouse hardware.

It also suggests that clearing WS_EX_TRANSPARENT is not, by itself, a complete official fix. The opposite state has also been reported in #41596, where the whole transparent overlay captures input.

Suggested official fix

Conceptually, when a non-empty pet hit region is applied:

1. Call setIgnoreMouseEvents(false) unconditionally, or verify the actual native state instead of trusting a cached mousePassthroughMode.
2. Apply the pet’s native input shape using a consistent physical/logical coordinate conversion.
3. Recalculate and reapply it after:
   • Wake Pet
   • switching pets
   • display/DPI changes
   • moving between monitors
   • every completed drag
4. When no interactive region exists, use setIgnoreMouseEvents(true, { forward: true }).
5. Ensure the defined hit region accepts mouse, touch and pointer input while the rest of the transparent overlay remains pass-through.

Regression coverage should include ARM64, 200% scaling, secondary displays, touch input, and repeated drags.

Related reports: #41465, #41501, #41506, #41535, #41596, #34227.