[Windows][Pets] Input region is offset; pet stays click-through after Windows reboots

[chenbocong-dev]

Environment

• Codex Windows package: OpenAI.Codex 26.901.1978.0, x64.
• Two monitors; portrait secondary monitor to the left. Primary logical resolution 2048x1152.
• Pet window DPI 120 (125% scaling).

Reproduction and impact

The pet is visible on the primary monitor, but right-clicking or dragging its body activates the desktop/window underneath. Both built-in and custom pets are affected. This has persisted for several days, including after full Windows reboots.

Read-only native scan (2026-09-04, UTC+8)

The helper used per-monitor-DPI-aware-v2 coordinates, in physical pixels.

• Overlay bounds: (1378,0)-(2344,1440), unchanged during the scan.
• Visible pet center, indicated by the user's cursor: (1841,741). WindowFromPoint selected the desktop.
• All 289 probes within +/-64 pixels of this point missed the overlay.
• Full overlay grid: 2400 probes, 24-pixel spacing. Only 323 selected the overlay: a 19x17 rectangle at sampled x=1390..1822, y=12..396, in its upper-left area. These are sampled ranges, not exact boundaries.
• Direct WM_NCHITTEST returned HTCLIENT at all 2400 grid points, with no failures or timeouts.
• Window visible, enabled, topmost; extended style 0x00280088. WS_EX_TRANSPARENT was NOT set.
• GetLayeredWindowAttributes failed; its zero alpha output is not evidence of actual zero opacity. GetWindowRgn returned 0; this is not proof of an empty region.

Already tried

• Reset saved pet position: moved it to the primary monitor, but did not fix input.
• Switched to a built-in pet.
• Fully exited and reopened Codex using its original icon.
• Rebooted Windows multiple times over several days.
• A temporary launcher requested --force-device-scale-factor=1, without improvement. Acceptance of this argument was not independently verified, so scaling is not ruled out. Normal launch has since been restored.

Expected / interpretation

The visible pet should receive right-click and drag input. The scan shows a mismatch between the visible body and the OS-selected input area. The exact cause is unconfirmed; please investigate input-shape application, coordinate conversion, and layered-window hit testing.

Potentially related: #34227, #41596. This report adds a spatial WindowFromPoint map and a reproduction without WS_EX_TRANSPARENT.

[github-actions]

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

• [Windows][Pets] 150% display scaling makes the floating pet non-interactive #42289
• [Windows] Desktop pet hit-testing and dragging break after moving or resizing the pet #42190
• Pet becomes unselectable after moving downward shortly after refresh on dual-monitor Windows #42469
• [Windows] Desktop pet becomes click-through and cannot be dragged #41535
• [Windows][Pets] Built-in and custom floating pets become click-through and cannot be dragged #41513

Powered by Codex Action

[XiaoShawn]

I can reproduce the same click-through failure on a different Windows configuration.

Environment

• Codex MSIX package: OpenAI.Codex 26.831.2377.0 x64
• Embedded desktop build: 26.831.21537 (Electron 42.3.0)
• Windows 10 Pro 22H2, build 19045.6466, x64
• Single 1440x900 display
• Built-in codex pet, mascot width 80 px

Actual behavior

The pet renders normally but is completely non-interactive:

• Hovering its visible body does not change the cursor.
• Clicks and drag attempts pass through to the desktop/window underneath.
• The pet cannot be moved or used.

Tried without effect

• Tuck Away / Wake Pet
• Fully exiting and relaunching Codex
• Switching to the built-in pet
• Backing up and removing only electron-avatar-overlay-open and electron-avatar-overlay-bounds, then relaunching

This rules out the custom pet asset and stale placement state for this reproduction.

Read-only native observation

A same-session Win32 inspection did not find a small transparent standalone pet HWND under the cursor. The visible Codex windows were a 468x900 Chrome_WidgetWin_1 and an offscreen 80x14 Chrome_WidgetWin_1; neither had WS_EX_TRANSPARENT. This appears consistent with a native-composed pet surface whose visual position and effective input region are out of sync, rather than the older transparent-style-only failure.

Please investigate the Windows native overlay/input-shape path on Windows 10 as well, including the case where no mouse-move event reaches the visible mascot.

[DoppeyFR67]

I'm also experiencing this on another Windows setup. The pet is visible and continues displaying activity, but clicks and drag attempts pass through to the window underneath.

Environment:

• Codex MSIX package: OpenAI.Codex 26.901.4073.0, x64
• Embedded desktop build: 26.901.31953
• Two monitors; saved display bounds report 2560x1440 for the primary and 3840x2160 for the secondary
• Custom v2 pet (spriteVersionNumber: 2)
• The official in-app update check reported that the app is up to date on September 4, 2026

The pet originally opened on the secondary monitor. Resetting only its saved placement while Codex was fully stopped successfully moved it to the primary monitor after relaunch, but did not restore clicking or dragging.

Read-only native diagnostics after the reset:

• The overlay was visible, enabled, layered, and topmost, with extended style 0x00280088; WS_EX_TRANSPARENT was not set on the top-level overlay.
• Its window rectangle was 773x1440, much larger than the mascot.
• All six sampled direct WM_NCHITTEST calls completed and returned HTCLIENT, including samples around the saved mascot position.
• WindowFromPoint at those locations selected underlying windows instead of the pet overlay.

This supports a mismatch between the rendered pet and effective mouse-input area, rather than a frozen window. The exact cause is still unconfirmed. No app binaries or mouse-handling code were modified.

[abraxas-von-abrasax]

Additional reproduction with isolation results on the current Windows package:

Environment

• ChatGPT/Codex desktop MSIX: OpenAI.Codex 26.901.4073.0 x64
• Windows 11 Pro, version 10.0.26200, build 26200
• GPU: AMD Radeon Graphics, driver 32.0.31041.1004
• Three displays; primary is 1920 x 1080 at 96 DPI
• Reproduces with built-in and custom pets

Isolation already completed

• Reset only the persisted pet overlay position/open state.
• Tested the pet on primary and secondary displays.
• Launched with --disable-gpu; process inspection confirmed the flag and --disable-gpu-compositing in renderer processes.
• Launched with a new temporary --user-data-dir; process inspection confirmed the main and child processes used the clean profile.
• Updated from 26.901.2854.0 to 26.901.4073.0, removed the temporary profile, and reproduced again under the normal profile.

None of these restored dragging, clicking, hover controls, or the voice button.

Native pointer evidence

With the physical pointer held over the visibly rendered pet body:

Pointer: 1835,959
Pet overlay HWND: 0xD1030
WindowFromPoint root HWND: 0x60EBA
Pointer resolved to pet overlay: false

The underlying window received the pointer.

The overlay was observed switching between two native states:

State A: ExStyle 0x2800A8, WS_EX_TRANSPARENT=true, 0/836 grid points resolved to the overlay
State B: ExStyle 0x280088, WS_EX_TRANSPARENT=false, 195/836 grid points resolved to the overlay
Direct WM_NCHITTEST at nine sampled locations: HTCLIENT, no timeouts

Physical interaction remained broken in both states. This supports an effective input-shape/visual-position mismatch or failed passthrough transition rather than GPU cache, custom-pet data, or ordinary Electron-profile corruption.

No raw logs, account details, private project paths, or screenshots containing task content are included.

[nyangela-gif]

Windows floating pet displays but ignores all mouse input

Environment:

• Windows 11 Pro, build 26200
• ChatGPT desktop 26.901.5003.0
• Two-monitor Windows setup
• App package status: Healthy

Problem:
The floating owl appears and animates, but it does not respond to clicking, dragging, or any of its controls. The /pet wake and tuck-away commands work.

Steps to reproduce:

1. Wake the floating pet with /pet.
2. Wait for the pet to appear.
3. Click the pet.
4. Attempt to drag it to another location.

Expected:
Clicking opens ChatGPT or the activity tray, and dragging changes the pet’s position.

Actual:
The pet remains visible but ignores all mouse input.

Recovery already attempted:

• Fully terminated and relaunched ChatGPT.
• Reset the saved pet position and overlay state.
• Restarted Windows.
• Updated ChatGPT from 26.901.4073.0 to 26.901.5003.0.
• Confirmed the Windows app package reports Healthy.
• Retested clicking and dragging on the new build.

Diagnostic result:
The app logs show the avatar-overlay window loading, becoming ready, and becoming visible without crashing. The failure appears limited to the Windows overlay’s mouse-input or hit-testing layer.

Current workaround:
Keep the pet tucked away.