Codex desktop pet reacts to hover but cannot be dragged on Windows

Codex
, , ,
1

Windows pet overlay reacts to hover but cannot be dragged

Environment

  • Codex desktop version: 26.825.3734.0
  • Chromium/Electron engine: 151.0.7922.174
  • Windows build: 22631.6199 (23H2, x64)
  • Display: 2560 x 1440 at 150% scaling (DPR 1.5)
  • Pet tested: built-in Codex pet and a valid custom pet

Problem

The floating pet reacts when the physical mouse approaches it, but pressing and dragging does nothing. No drag/grab cursor appears. The issue occurs with both the built-in pet and a custom pet.

Steps to reproduce

  1. Open the floating pet in Codex desktop on Windows.
  2. Move the physical mouse over the pet; the proximity/hover animation reacts.
  3. Hold the left mouse button on an opaque part of the pet.
  4. Move the mouse while holding the button.

Expected result

The pet receives pointerdown/pointermove/pointerup and moves to the new screen position.

Actual result

The pet does not move. Instrumentation installed in the avatar-overlay renderer records zero trusted pointer or mouse events for the physical drag. The underlying main window receives the native hit instead.

Diagnostics already performed

  • A CDP/renderer-level drag succeeds and updates the persisted overlay bounds, proving the pet assets and application drag handler work.
  • A physical Windows mouse drag at the corresponding screen coordinates produces 0 renderer pointer/mouse events and does not update the overlay bounds.
  • Reproduces with built-in and custom pets.
  • Reinstalling the custom pet directory with verified SHA-256 hashes does not help.
  • Changing display scaling does not help.
  • Launching with --disable-gpu --disable-gpu-compositing does not help.
  • Calling BrowserWindow.setIgnoreMouseEvents(false) for the avatar overlay does not restore physical input.
  • The application package reports Status=Ok.

Suspected area

The Windows transparent/frameless avatar overlay input policy, especially the transition between global pointer-proximity tracking and native BrowserWindow.setIgnoreMouseEvents(...) handling. Hover-like proximity feedback works, while the renderer never receives the physical button press.

2

I also encountered the same problem. After switching pets, there was one chance to drag, but after dragging, I could no longer click. I even reinstalled codex, but it didn’t work

3

Welcome to the forum!

You are welcome to discuss Codex issues here. However, the official place to report and track them is the OpenAI Codex GitHub issue tracker.

I asked ChatGPT to look for the closest related issue, and it identified:

If that issue matches your problem, consider adding a :+1: reaction on the GitHub issue itself—not only on this forum topic. Reactions on GitHub can help the developers gauge the number of affected users.

If it does not describe the same problem, search the existing Codex issues for a closer match. If you cannot find one, open a new issue and include as much relevant detail as possible.

4

I can confirm the same complete click-through failure on a current Windows build, with additional synchronized native-input evidence.

Environment

  • Codex Windows package: OpenAI.Codex 26.825.5331.0 x64
  • Internal desktop release: 26.825.41651
  • Windows 11 25H2, build 26200.9168, x64
  • Pet: bundled Dewey
  • Reproduced on 2026-08-29
  • Frequency after the failure begins: 100%

Behavior

  • Dewey still reacts/animates when the pointer hovers nearby.
  • Holding LMB over the visible pet and moving the pointer never begins a drag.
  • The Codex window underneath receives the button input.
  • Tuck Away → Wake, a full Codex restart, and a full Windows reboot did not recover interaction.

Native diagnostic evidence

  • The visible avatar-overlay window retained extended style 0x2800A8, including WS_EX_TRANSPARENT.
  • During a physical LMB hold and movement, WindowFromPoint and pointer capture resolved to the primary Codex window underneath, not the overlay.
  • A 4-pixel grid scan over the complete overlay found 0 hit-testable points, including the visible Dewey area.
  • The overlay bounds did not change during the physical drag.
  • As a control, externally moving the same overlay window with SetWindowPos moved Dewey immediately and Codex persisted the updated coordinates. I restored the exact original position afterward.

This rules out the bundled asset, animation, renderer, saved position, and native window movement. The failure is specifically in the Windows overlay input-shape / pointer-interactivity handoff: mouse movement is forwarded sufficiently for hover, while button input remains click-through.

I also added the complete sanitized result to openai/codex GitHub issue #34227.

The same report has also been escalated through the private OpenAI Support chat. No raw logs, personal data, local paths, customer documents, or repository contents are included.

5

Me ha pasado igual, pensaba que era un problema de mi PC, he borrado todos los proyectos y el problema persiste, soy usuaria de la versiĂłn pro, carĂ­sima como para que la app de escritorio del PC Windows, haga esto. Y nadie dice nada.

6

Same issue on Windows desktop.

7

Still haven’t been solved. I miss my Fireball so much!

8

I was having the exact issue. Here’s the simple thing that fixed mine:

Open Settings > Pets and click the refresh button at the top.

This reset my pet and allowed me to move it. This only allows me to move it once but at least it moved.

9

same problem

If I change pets like Dillyn suggested I can get click/hold to drag but the cursor jumps to top of the page and I have limited range of motion where I can put him and once I let him go he’s stuck there and back in transparent overlay mode until selecting another pet.

Video of the bug in action:

streamable dot com/5n79ee

10

Windows floating PET is visible, but its clickable area is displaced after refresh or drag

I am experiencing a reproducible issue with the floating PET in the ChatGPT/Codex desktop app for Windows.

Environment

  • Windows 11, 64-bit
  • Desktop app version: 26.901.5280.0
  • Tested with a valid custom PET and with built-in PETs
  • Custom sprite sheet: transparent PNG, 1536 Ă— 1872

Expected behavior

The PET should respond when I click or drag its visible image. After moving it, the clickable area should remain aligned with the rendered PET.

Actual behavior

The PET is visible near the bottom-right of the screen, but clicking or dragging the visible image does nothing. The click can reach the window behind it instead.

After opening Settings > Pets and selecting Refresh, the PET briefly appears near the top of the screen. At that moment, I can click it and move it with some limitations. When I release the mouse, the rendered PET moves or returns lower on the screen, but its clickable area appears to remain much higher. I can no longer interact with the visible PET.

The attached video shows the visual PET and its active click area becoming separated.

Steps to reproduce

  1. Open the ChatGPT/Codex desktop app on Windows.
  2. Select a PET and show the floating PET with /pet.
  3. Try to click or drag the visible PET near the bottom-right of the screen.
  4. Open Settings > Pets and select Refresh.
  5. Observe that the PET briefly appears near the top of the screen.
  6. Click and drag it while it is in that upper position.
  7. Release the mouse.
  8. Try to click the visible PET again. The active click area is no longer aligned with the image.

Tests performed

  • Restarted the desktop app.
  • Hid and reopened the PET with /pet.
  • Refreshed the PET from Settings.
  • Switched between a custom PET and built-in PETs.
  • Confirmed that the custom sprite sheet meets the documented dimensions.
  • Compared the PET’s reported visual bounds with the Windows mouse hit-test result.
  • Verified that the rendered PET can be repositioned through direct window movement, which indicates that the overlay itself can move.

Diagnostic finding

Verified observation: the rendered PET and the clickable region use different screen positions after refresh or after releasing a drag. The visible PET is lower, while the active region remains above it.

Probable cause, not confirmed: the floating overlay retains stale hit-test coordinates, or its transparent input region is not recalculated after the PET is laid out or moved.

This does not appear to be caused by the custom sprite sheet because the same interaction problem was reproduced with built-in PETs.

Temporary workaround

I created a small local control that moves the PET overlay through Windows window positioning rather than through the displaced mouse region. It was tested successfully and registered 22 movements. This confirms a workaround, but it does not fix the underlying hit-test problem in the desktop app.

This behavior appears related to the existing GitHub report:

openai/codex/issues/41465

I can provide additional logs or testing details if useful.

Internal evidence summary — do not paste unless requested

  • Recording duration: approximately 40 seconds.
  • Recording resolution: 1332 Ă— 1034.
  • The native overlay exists and renders the PET correctly.
  • The visual accessibility bounds place the PET near the lower-right area.
  • Windows hit testing at the visible PET position resolves to the underlying app instead of the PET overlay.
  • Refreshing changes the rendered position but does not keep the input region synchronized.
  • Direct repositioning of the overlay works and was restored after controlled tests.

Privacy check

The public text contains no username, local file path, process ID, window handle, account identifier, or private project information. Review the video once before uploading in case any notification or personal content appears outside the tested app window.

11

HI, I just got access to Astra and it was able to work-up a solution for at least the current working session. Following the moderator’s guidance, I’ve added the detailed native Windows diagnostics to the existing GitHub issue (openai/codex/issues/41465) (new user so can’t post links yet)

Here’s what Astra has to say in brief: "I reproduced this and found a working temporary workaround with Codex’s assistance.

On Codex 26.901.6511.0 / Windows 11 Pro, the pet animated and displayed activity, but clicks went directly into Word or other windows behind it. Restarts, switching pets, changing zoom, and disconnecting external monitors did not fix it.

The useful diagnostic difference was:

  • Clearing the Windows click-through flag (WS_EX_TRANSPARENT), including on the inspected child windows, did not restore interaction.
  • Additionally clearing the top-level overlay’s layered-window flag (WS_EX_LAYERED) changed Windows’ hit-test result to the correct overlay, and I confirmed that pet interaction worked during the test.

This is a session-only workaround verified on my machine, not a universal or permanent fix. It points toward the overlay’s layered-window input handling, but does not prove the exact underlying cause. We still need to check broader rendering and transparent-area click-through behavior.

No app files or saved settings were changed. Please don’t reuse another person’s window handles/PIDs; the experiment targeted specifically identified live windows.