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

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

• #34012

Powered by Codex Action

Additional Windows data point on the current Microsoft Store package OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0.

Environment:

• Windows Enterprise, x64, build 26200
• Valid custom v1 pet atlas (1536x1872, 8x9) selected; asset validation passes.

Observed behavior:

• The pet remains visible and its normal animation still plays.
• Hover still triggers the pet's hover animation.
• However, mouse down/click and drag do not register on the visible mascot at all: it cannot be moved, and clicking it no longer brings the Codex desktop app to the foreground.
• Resetting only the persisted avatar-overlay bounds/open state and relaunching Codex recreated fresh default bounds, but did not restore click or drag handling.

This further points away from the custom asset or saved coordinates and toward the transparent overlay hit-testing / mouse-passthrough path. In this instance the failure appears to cover the full visible mascot, rather than only its lower portion.

I can reproduce the complete/full-overlay form of this issue.

• Codex Windows version: 26.715.4045
• Previous working version: 26.715.2305
• Display setup: one 1920×1080 display; no secondary monitor
• Affects the bundled/default pet and every custom pet
• Resetting bounds, changing pets, restarting Codex, and forcing

non-native rendering do not restore dragging

Live inspection shows the overlay remains click-through
(WS_EX_TRANSPARENT). The pet overlay starts non-interactive and does not
transition out of mouse passthrough, preventing pointer-down and drag-start
events from reaching the renderer.

The Electron executable is identical between the working and failing
packages, so the regression most likely resides in the packaged Codex
JavaScript/resources or rollout state.

Definitive root-cause update (Windows, 2026-07-21)

The complete/full-overlay failure still reproduces after the Microsoft Store update to OpenAI.Codex_26.715.8383.0_x64.

The earlier “hit-region desynchronization” theory does not explain this full failure. Live native-window testing isolates the broken segment to Electron's Windows mouse-forwarding path used while the transparent overlay is click-through.

Reproduction and isolation

• Dual-monitor Windows setup with mixed scale factors (100% and 125%).
• All bundled pets and multiple separately validated custom v2 pets behave identically.
• The pet remains visible and animated, but hover/press/drag never activates.
• During a 15-second physical hover over the visible mascot, the overlay remained WS_EX_TRANSPARENT for 478/478 samples; it became interactive 0 times.
• Posting the same WM_MOUSEMOVE that Electron's forwarder is intended to deliver directly to the overlay's Chrome_RenderWidgetHostHWND at a coordinate inside the visible mascot immediately changed the top-level overlay from passthrough to interactive:
• before: 0x800A8 (WS_EX_TRANSPARENT set)
• after: 0x80088 (WS_EX_TRANSPARENT cleared)
• Posting a move at a blank overlay coordinate restored 0x800A8.

That experiment bypasses only the native forwarding stage. It demonstrates that the following downstream stages are functioning:

1. Chromium renderer pointer processing
2. DOM hit testing of the mascot
3. the renderer-to-main pointer-interactivity IPC
4. the existing setIgnoreMouseEvents(false) transition

The failing stage is therefore before the renderer: physical WM_MOUSEMOVE events are not being forwarded into the ignored Electron window.

Packaged app behavior

The current packaged desktop code still has this state model:

• when the desired state first becomes passthrough, call setIgnoreMouseEvents(true, { forward: true });
• cache that desired state in a boolean;
• skip later calls while the boolean remains true.

The resume path restores layout/display/bounds but does not explicitly re-arm the mouse forwarder. Consequently, lifecycle callbacks can run without invoking Electron again because the cached desired passthrough state has not changed.

Electron's Windows implementation of forward: true uses a global WH_MOUSE_LL hook and also caches whether forwarding is enabled. Windows documents that a low-level hook can be silently removed after its timeout; the application cannot determine that the hook was removed. See:

• Electron BrowserWindow.setIgnoreMouseEvents: https://www.electronjs.org/docs/latest/api/browser-window
• Microsoft LowLevelMouseProc: https://learn.microsoft.com/windows/win32/winmsg/lowlevelmouseproc

The remaining low-level ambiguity is only whether this instance failed during hook installation or the hook was later silently removed. Windows exposes no reliable signal for that distinction. Both cases have the same application-level defect: the desired-state booleans remain “forwarding enabled,” so Codex never retries or uses a fallback.

This also explains the intermittent history: recreating the overlay/window can make dragging work temporarily, then the hook/forwarder stops and the stale state prevents recovery.

Suggested robust fix

Do not make pet hit testing depend exclusively on the WH_MOUSE_LL forwarding hook.

1. While the overlay is visible and in passthrough mode, sample screen.getCursorScreenPoint() at about 30–60 Hz (or use a raw-input equivalent).
2. When the cursor is within the overlay bounds, feed the point through the existing cursor-to-overlay path / webContents.sendInputEvent({ type: "mouseMove", ... }).
3. Re-arm pointer forwarding on ready-to-show, show, resume/screens-wake, and display add/remove/metrics changes without allowing the desired-state cache to suppress the re-arm.
4. Track “desired passthrough state” separately from “forwarder health/installation state,” and log installation/re-arm failures.
5. Stop sampling when the overlay is hidden or destroyed.

Regression/acceptance matrix

• 10 cold launches
• 20 sleep/resume cycles
• 20 cross-monitor drags in each direction between 100% and 125% displays
• bundled pets and valid custom v2 pets
• overlay hide/show and monitor reconnect
• blank transparent regions remain click-through
• no global mouse freeze or external helper/hook required

This is no longer an asset, atlas, saved-bounds, DPI-coordinate, or drag-algorithm hypothesis: direct message injection verifies the renderer-side interaction chain end to end.

Definitive root-cause update (Windows, 2026-07-21)

The complete/full-overlay failure still reproduces after the Microsoft Store update to OpenAI.Codex_26.715.8383.0_x64.

The earlier “hit-region desynchronization” theory does not explain this full failure. Live native-window testing isolates the broken segment to Electron's Windows mouse-forwarding path used while the transparent overlay is click-through.

Reproduction and isolation

• Dual-monitor Windows setup with mixed scale factors (100% and 125%).
• All bundled pets and multiple separately validated custom v2 pets behave identically.
• The pet remains visible and animated, but hover/press/drag never activates.
• During a 15-second physical hover over the visible mascot, the overlay remained WS_EX_TRANSPARENT for 478/478 samples; it became interactive 0 times.
• Posting the same WM_MOUSEMOVE that Electron's forwarder is intended to deliver directly to the overlay's Chrome_RenderWidgetHostHWND at a coordinate inside the visible mascot immediately changed the top-level overlay from passthrough to interactive:
• before: 0x800A8 (WS_EX_TRANSPARENT set)
• after: 0x80088 (WS_EX_TRANSPARENT cleared)
• Posting a move at a blank overlay coordinate restored 0x800A8.

That experiment bypasses only the native forwarding stage. It demonstrates that the following downstream stages are functioning:

• Chromium renderer pointer processing
• DOM hit testing of the mascot
• the renderer-to-main pointer-interactivity IPC
• the existing setIgnoreMouseEvents(false) transition

The failing stage is therefore before the renderer: physical WM_MOUSEMOVE events are not being forwarded into the ignored Electron window.

Packaged app behavior

The current packaged desktop code still has this state model:

• when the desired state first becomes passthrough, call setIgnoreMouseEvents(true, { forward: true });
• cache that desired state in a boolean;
• skip later calls while the boolean remains true.

The resume path restores layout/display/bounds but does not explicitly re-arm the mouse forwarder. Consequently, lifecycle callbacks can run without invoking Electron again because the cached desired passthrough state has not changed.

Electron's Windows implementation of forward: true uses a global WH_MOUSE_LL hook and also caches whether forwarding is enabled. Windows documents that a low-level hook can be silently removed after its timeout; the application cannot determine that the hook was removed. See:

• Electron BrowserWindow.setIgnoreMouseEvents: https://www.electronjs.org/docs/latest/api/browser-window
• Microsoft LowLevelMouseProc: https://learn.microsoft.com/windows/win32/winmsg/lowlevelmouseproc

The remaining low-level ambiguity is only whether this instance failed during hook installation or the hook was later silently removed. Windows exposes no reliable signal for that distinction. Both cases have the same application-level defect: the desired-state booleans remain “forwarding enabled,” so Codex never retries or uses a fallback.

This also explains the intermittent history: recreating the overlay/window can make dragging work temporarily, then the hook/forwarder stops and the stale state prevents recovery.

Suggested robust fix

• Do not make pet hit testing depend exclusively on the WH_MOUSE_LL forwarding hook.
• While the overlay is visible and in passthrough mode, sample screen.getCursorScreenPoint() at about 30–60 Hz (or use a raw-input equivalent).
• When the cursor is within the overlay bounds, feed the point through the existing cursor-to-overlay path / webContents.sendInputEvent({ type: "mouseMove", ... }).
• Re-arm pointer forwarding on ready-to-show, show, resume/screens-wake, and display add/remove/metrics changes without allowing the desired-state cache to suppress the re-arm.
• Track “desired passthrough state” separately from “forwarder health/installation state,” and log installation/re-arm failures.
• Stop sampling when the overlay is hidden or destroyed.

Regression/acceptance matrix

• 10 cold launches
• 20 sleep/resume cycles
• 20 cross-monitor drags in each direction between 100% and 125% displays
• bundled pets and valid custom v2 pets
• overlay hide/show and monitor reconnect
• blank transparent regions remain click-through
• no global mouse freeze or external helper/hook required

This is no longer an asset, atlas, saved-bounds, DPI-coordinate, or drag-algorithm hypothesis: direct message injection verifies the renderer-side interaction chain end to end.

Follow-up: physical click-target capture

I captured physical left-button transitions while reproducing the complete drag failure on Codex Windows 26.715.8383.0.

A read-only probe sampled the pet overlay's extended style and used WindowFromPoint at each physical button-down. Multiple attempted drags began on the visible mascot and were confirmed to start inside the overlay bounds.

Sanitized result:

BUTTON_DOWN insideOverlay=True overlayTransparent=True target=UNDERLYING_WINDOW
BUTTON_UP   overlayTransparent=True overlayBoundsUnchanged

For every captured in-overlay press:

• the top-level pet overlay still had WS_EX_TRANSPARENT set (0x2800A8);
• Windows resolved the physical click to the window underneath, not the pet overlay;
• the pointer moved while held, but the overlay bounds did not change.

This is physical-input confirmation that click-through persists through button-down, so the renderer never receives the pointerdown needed to begin the existing drag path. Combined with the earlier direct WM_MOUSEMOVE injection result, this further isolates the failure to the pre-renderer Windows mouse-forwarding/interactivity handoff.

I also tested continuously clearing WS_EX_TRANSPARENT externally. That did not reliably restore dragging, indicating that changing the native style bit alone is not equivalent to re-arming Electron's internal ignore/forwarding state.

The raw diagnostic log is intentionally not attached because it contains unrelated window titles, process IDs, native handles, timestamps, and screen coordinates.

Conclusion: The pet assets and drag code are functioning. On Windows, physical mouse movement is not reaching the ignored Electron overlay, so it remains click-through and sends clicks to the window underneath. Only whether the forwarding hook failed initially or was later removed remains unresolved.
So this requires a Codex/Electron Windows fix; changing pet assets or saved positions cannot solve it.

Additional reproduction: remote-desktop display transitions are a reliable trigger.

Environment

• Codex Desktop Microsoft Store package: OpenAI.Codex_26.715.10079.0_x64
• Windows x64
• One local display at 2560x1440
• UU remote desktop session temporarily changes the controlled machine to 1024x768, then restores the local layout when the session ends
• Reproduces with a custom v2 pet; this looks independent of pet art

Steps to reproduce

1. Wake the desktop pet and confirm it can be clicked and dragged locally.
2. Start a UU remote-desktop session that changes the controlled machine's display resolution.
3. End the session and let the local display return to its original resolution.
4. Try to click or drag the visible pet locally.

Actual behavior

After the display transition back to the local layout, the pet remains visible but no longer accepts click or drag input. The symptom recurs on subsequent UU sessions that change the resolution.

The persisted overlay state contained a per-resolution entry for 1024x768 with stale-looking bounds. Removing only electron-avatar-overlay-bounds from Codex's persisted global state and relaunching the app made Codex regenerate bounds for both 2560x1440 and 1024x768, and restored interaction for this instance.

Expected behavior

On every display-metrics/resolution transition, the pet overlay should re-evaluate its saved bounds and re-arm its Windows pointer-forwarding / interactivity state. A remote-desktop resolution round trip should not leave a visible pet click-through or non-draggable.

This is a narrow remote-desktop trigger that may help exercise the same display-change lifecycle described in this issue.

Additional confirmation on a newer Windows package: OpenAI.Codex 26.715.10079.0.

• Both bundled/default pets and a validated custom v2 pet are affected.
• Fully restarting Codex and restarting Windows do not restore dragging.
• Hover interaction still reaches the mascot and triggers its jump animation, but holding the primary button and moving never starts a drag.
• This worked before the update; the previously installed package was 26.715.7063.0.

That hover-vs-drag distinction suggests the visible mascot hit region is still receiving pointer interaction, while the drag-start/native window-drag transition fails. Inspection of the packaged Windows renderer shows it calls compositionHost.performWindowDrag() and skips renderer-side fallback movement when the native call reports success, so native drag handling or success reporting may be involved.

Full reproduction details were also recorded in the now-consolidated duplicate: https://github.com/openai/codex/issues/34309#issuecomment-5056932758

Additional Windows reproduction and workaround evidence from Codex Desktop package 26.715.10079.0:

• The failure reproduced with a validated custom v2 pet (Teddy) while hover interaction and the pet's animation still worked; holding the primary button and moving did not start a drag.
• The same behavior was observed with the bundled/default pet, so this is not sprite or pet-manifest specific.
• Clearing the persisted electron-avatar-overlay-bounds and restarting Codex/Windows did not restore dragging.
• Clearing the native WS_EX_TRANSPARENT style bit by itself also did not reliably restore Codex's internal drag chain.
• A minimal external compatibility overlay did restore the complete behavior: it captures only the mascot hit area so the underlying window does not receive the drag, moves the Codex pet window with SetWindowPos, and forwards WM_LBUTTONDOWN/WM_MOUSEMOVE/WM_LBUTTONUP to the pet's Chrome_RenderWidgetHostHWND. This restored movement, the running animation during drag, and normal interaction.
• This suggests the broken segment is the Windows transparent-overlay/native input-forwarding or native window-drag bridge, rather than the pet asset, saved bounds, or animation data.

The workaround is intentionally external and reversible; no signed WindowsApps files were modified.

Additional Windows reproduction from a custom v2 pet:

• Codex Desktop Windows package: 26.715.3651.0
• Custom pet: Little Knight, using a v2 manifest with spriteVersionNumber: 2 and spritesheet.webp
• Before switching to/upgrading to this v2 pet, the mascot could be dragged from any visible part of the pet.
• After selecting the v2 pet, only a small specific point/region accepts pointer-down and starts a drag; clicks on most of the visible body do nothing.
• The pet renders correctly and the asset loads; there is no hitbox or interaction setting in pet.json.

This initially looked like a mistake in the v2 custom pet, but the symptom matches the overlay hit-region/pointer-passthrough regression described here. Expected behavior is for the full visible pet area, including transparent padding around the sprite, to remain clickable and draggable.

Additional confirmation on a newer Microsoft Store build: OpenAI.Codex 26.721.4979.0 on Windows x64.

New reliable trigger:

• Physically powering the local monitor off and back on can leave the visible pet with an incorrect/nonfunctional click and drag region, even without a remote-desktop session or resolution change.

Restart result:

• Fully exiting and reopening Codex does not recover interaction in this instance.
• A read-only native-window check confirmed that the Codex process and pet overlay window were newly created after restart, but the new overlay still remained WS_EX_TRANSPARENT (0x002800A8) and physical interaction did not recover.
• No external mouse injection, watcher, startup entry, or scheduled recovery task was active during this confirmation.

Current packaged-code observation:

• The avatar controller still caches the desired passthrough state in mousePassthroughEnabled and suppresses repeated setIgnoreMouseEvents(...) calls while that boolean is unchanged.
• handleDisplayChanged restores/reclamps layout and persisted bounds but does not force a pointer-forwarding re-arm.
• handleResume clears the suspended flag and restores/switches display geometry, but likewise does not invalidate the passthrough cache or reapply setIgnoreMouseEvents(true, { forward: true }).

This extends the earlier UU remote-resolution reproduction: ordinary monitor power/display wake transitions are sufficient, and process recreation is not a reliable workaround. It also shows the defect remains present in the newer 26.721.4979.0 package.

Additional reproduction on Windows with OpenAI.Codex 26.727.6591.0.

The two visible controls below the pet - the voice button and the collapse button - sometimes stop responding to clicks. They remain visible, but mouse input seems to pass through the overlay.

Reproduction

1. Select a valid custom v2 pet and wake it.
2. The two buttons below the pet may become unresponsive.
3. Tucking and waking the same pet does not help.
4. Resizing the Codex window does not help.
5. Simply selecting another pet does not always help.
6. Selecting another pet, tucking it, and waking it can temporarily restore the buttons.
7. Selecting the custom pet again and tucking/waking it reproduces the problem.

Pet asset check

I reproduced this with two versions of the same custom pet:

• the original validated v2 atlas;
• a test version with every frame reduced to 85%, leaving more transparent padding around the sprite.

Both atlases:

• are 1536x2288;
• use the 8x11 v2 layout;
• have spriteVersionNumber: 2;
• pass validation without errors or warnings;
• have no RGB residue in fully transparent pixels.

The smaller version has the same problem, so sprite size, padding, and transparency do not appear to be the cause.

Packaged app observation

While inspecting the packaged Windows app, I noticed that a custom avatar is temporarily resolved as null while its data is loading. During this state, the overlay sends:

• avatar-overlay-pointer-interaction-changed with isInteractive: false;
• avatar-overlay-composition-changed with a null state.

After the custom avatar finishes loading, the controls may become visible while the overlay is still non-interactive and passing clicks through.

This may be another trigger for the stale Windows pointer-forwarding state already described in this issue.

Expected behavior: after loading a custom avatar, switching pets, or tucking and waking the pet, Codex should rebuild the interactive regions and restore mouse forwarding before displaying the controls.

Additional reproducible observation: size-dependent hit region near the upper-left

A user found a reliable temporary way to drag the Pet after the normal visible sprite stops accepting pointer input:

1. The Pet is normally used at the minimum size.
2. After the bug occurs, dragging from the visible mascot no longer works.
3. Increase the Pet size slider to its maximum.
4. Slowly move the pointer around the Pet. A very small hover-reactive area can be found near the mascot's upper-left region.
5. Starting the drag from that tiny reactive area successfully moves the Pet.
6. Move the Pet to the desired location, then reduce the size to minimum again.
7. At minimum size, the reactive area appears to shrink disproportionately—effectively to a nearly undetectable point—so hover and drag stop working again.

This workaround does not permanently repair the state; the input problem returns after resizing back down.

This appears distinct from the complete Windows mouse-forwarding failure where no part of the overlay reacts at all. In this case, hover and drag are still functional inside a tiny, offset region, and increasing the Pet's visual size makes that region large enough to locate.

Expected: the clickable/draggable hit region should remain aligned with the visible mascot and scale linearly with the Pet size setting.

Possible direction (inference): the hit-region bounds or scale may be stale, anchored to the upper-left, or receiving the size factor more than once. Recompute the mascot bounds and native pointer-interaction region after every size-slider change, and add a regression test covering minimum → maximum → minimum sizing while verifying that the full visible mascot remains draggable.

补充验证（2026-08-24，Windows）：

• 我在本机当前安装的 OpenAI.Codex 26.818.5229.0 上使用最新 Codex 项目，至今未能复现本 Issue 描述的命中区域错位、鼠标穿透或拖拽失效。
• 我检查了本地的 Codex-Dream-Skin 与 Zeyin-Melody-Skin-for-Codex 项目。它们只通过 loopback CDP 注入主界面 CSS/DOM；项目 QA 还明确验证宠物辅助窗口保持透明，因此没有修改 avatar-overlay、setIgnoreMouseEvents 或宠物原生拖拽逻辑。
• 对当前 app.asar 的只读检查显示，当前包已经包含针对性机制：通过 ResizeObserver/MutationObserver 重新测量 [data-avatar-overlay-hit-region]，过滤 pointer-events:none 的区域，并通过 setInputShape 同步输入形状；主进程同时分离 inputShape、pointerInteractive 与 mousePassthroughMode，并在窗口显示、显示器变化、恢复等生命周期重新应用交互策略，还能刷新当前鼠标位置。
• 这与旧版报告中的缓存 passthrough/forwarder 状态路径不同，也可能解释了为什么在当前版本不再复现。
• 本次没有修改官方安装包，也没有提交上游代码修复；Issue 先保持 open。若仍有特定旧版或当前版本能够复现，欢迎提供版本号、显示器/DPI、宠物尺寸和触发步骤，以便继续定位。

Current-version mixed-DPI correlation and recovery (Windows, 2026-08-24)

I can reproduce the non-interactive pet state on Codex Desktop 26.818.5229.0 with mixed display scaling.

Environment

• Windows x64
• 3840×2160 display at 150% scaling (DPI 144)
• 3072×1920 display at 200% scaling (DPI 192)
• Observed with a custom v2 pet; bundled pets have not yet been tested in this setup

Observed behavior / recovery

1. While the pet was on the 200%-scaled display, it remained visible but could not be dragged. Single-clicking it also no longer opened or focused Codex.
2. Restarting Codex did not restore interaction while the pet remained on that display.
3. Moving the overlay back to the 150%-scaled display using native window positioning restored normal manual dragging and clicking.
4. Changing the Windows display scaling also restored interaction immediately.

The exact transition that initially breaks interaction has not yet been isolated, but the recovery is strongly correlated with the per-monitor scale/DPI change.

Local native-window observations

• On the 200% display: overlay physical bounds were 816×800 and the window DPI was 192.
• On the 150% display: overlay physical bounds were 613×600 and the window DPI was 144.
• Codex renderer processes were launched with --device-scale-factor=1.5, matching the 150% display rather than the 200% display.

This suggests a mixed-DPI coordinate conversion or stale input-shape/hit-test region when the overlay is hosted on a differently scaled monitor. It may be worth recomputing and reapplying the input shape and pointer-interactivity state on WM_DPICHANGED, monitor moves, and display-scale changes.

Current workarounds

• Keep the pet on the 150%-scaled display.
• Change the Windows display scaling to force an interaction-region refresh.

Minimal size-matrix follow-up with a custom v2 pet (Windows, 2026-08-25)

I ran the size leg locally on Codex Desktop 26.818.5229.0 with the custom yukie-head / “Yukie Head” pet (spriteVersionNumber: 2). The installed spritesheet matches the workspace source (SHA-256: 1C92859C0CB66480F00EB44F29F6E3614D598A68B4EEC700C6ED04160E1F8C8C) and passes the v2 atlas validation.

The renderer is launched with --device-scale-factor=1.5. This machine currently exposes only one monitor (DISPLAY1, 2560×1600 physical) at 150% scaling / DPI 144, so I could not execute the 200% or cross-monitor legs. I am marking those legs as blocked rather than treating them as passes.

| Leg | Result |
|---|---|
| 150%, minimum → maximum → minimum | Executed: slider read back 80.0 → 224.0 → 80.0. The pet remained visually rendered at all three stages; the UIA image boxes were 120×131, 336×365, and 120×131. |
| 200%, minimum → maximum → minimum | Blocked: no DPI-192 monitor is available on this machine. |
| 150% → 200% → 150% move | Blocked: no second monitor is available. |

For each 150% stage I sampled native WindowFromPoint at the top, middle, and bottom of the visible Yukie image. All 9/9 samples resolved to the main ChatGPT window, not the pet overlay; an additional spot check of the overlay controls also resolved to the main window. The pet stayed visible in the screenshots, so this run reproduced a complete mouse-passthrough state rather than a size-dependent recovery.

In the clean rerun, the 80 px image box was at the same horizontal position (X=2225) before and after the round trip, so I did not get a repeatable size/layout drift from resizing alone.

This local run does not isolate the transition that first enters the non-interactive state, and it does not establish the 200% mixed-DPI behavior because the required hardware is unavailable. It does show that the current version can still reach a visible-but-fully-passthrough state at 150% with a valid custom v2 pet after a minimum → maximum → minimum size sequence.

Confirmed on newer Windows package 26.825.3734.0 (single display, 100% scale)

This still reproduces on the current Microsoft Store package:

• Package: OpenAI.Codex_26.825.3734.0_x64__2p2nqsd0c76g0
• Package status: Ok, Store-signed
• Display: one 1920×1080 display
• Windows scaling: 100% (DPI 96)
• Pet: validated custom v2 atlas, 1536×2288, 8×11, RGBA lossless WebP
• Atlas validation: 0 errors, 0 warnings; installed SHA-256 matches the validated source

Observed behavior

• The pet remains visible and animated.
• The pet cannot be clicked or dragged.
• Activity/notification messages appear, but clicking them does nothing.
• Restarting the pet, restarting the desktop app, and restarting Windows do not restore interaction.
• The failure reproduces at both the supported minimum size (80 px) and maximum size (224 px).

Native-window evidence

The visible avatar overlay is present as a layered, topmost tool window. I sampled the complete overlay with Win32 WindowFromPoint on an 8-pixel grid:

• overlay bounds sampled: 772×1080
• interactive samples resolving to the avatar overlay: 0
• a point inside the expected visible mascot rectangle resolves to the underlying main ChatGPT window instead
• after the supported 80 → 224 px size change, the overlay remained non-interactive and WS_EX_TRANSPARENT was present

The current packaged code measures [data-avatar-overlay-hit-region], sends regions through setPointerRegions, and applies them through BrowserWindow.setInputShape(...), with setIgnoreMouseEvents(true, { forward: true }) as the fallback. In this reproduction the effective native input region is empty, and the fallback never transitions the overlay out of mouse passthrough.

This is a full-overlay failure on a single 100%-scaled display, so it is not limited to mixed-DPI or multi-monitor setups. No personal logs, chat text, or pet artwork are attached.