Repository navigation
Codex Desktop v2 pet look directions ignore the physical mouse and only follow the Computer Use cursor on Windows #33224
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop 26.707.72221, released July 14, 2026.
The installed Microsoft Store/AppX package version is 26.707.9981.0; this is package metadata and is not the user-facing version shown in the About dialog.
What platform is your computer?
Windows 25H2, build 26200.8737, x64.
What issue are you seeing?
A custom v2 pet's 16 look-direction frames do not respond to the user's physical mouse cursor. The same pet correctly changes look direction when a Computer Use virtual cursor is active.
Other physical-pointer interactions work normally:
- Hovering the pet triggers and plays the jumping animation.
- Dragging the pet left/right triggers the corresponding running animation.
- Idle breathing and blinking play normally.
This isolates the problem to the look-direction input path rather than the spritesheet, animation timer, reduced-motion settings, or pointer interaction generally.
The pet is a valid Codex v2 package:
spriteVersionNumber: 2- 8 columns × 11 rows
- 1536 × 2288 WebP with alpha
- Rows 9–10 contain all 16 clockwise look directions
- The v2 atlas validator passes with no errors or warnings
What steps can reproduce the bug?
- On Codex Desktop for Windows, install and select a valid v2 custom pet with populated direction rows 9 and 10.
- Enable the floating pet.
- Move the physical mouse cursor around the pet and around the screen.
- Observe that the pet never selects any of the 16 look-direction frames.
- Hover or drag the pet and confirm that normal physical-pointer interactions still work.
- Start a Computer Use interaction that exposes the virtual cursor.
- Move the Computer Use cursor and observe that the pet now selects direction frames.
What is the expected behavior?
When Computer Use is inactive, the v2 pet should look toward the user's physical mouse cursor. When Computer Use is active, its virtual cursor may reasonably take precedence.
What do you see instead?
The physical cursor never drives the 16-direction gaze. Only the Computer Use virtual cursor does.
Additional information
Inspection of the bundled Windows Desktop code suggests the physical cursor is available in the main process but is not forwarded into the renderer's look-direction state.
The main process obtains a physical cursor position through logic equivalent to:
compositionHost.getCursorPosition() ?? screen.getCursorScreenPoint()That position is passed only through a synthetic webContents.sendInputEvent({ type: "mouseMove", ... }), which supports hover/drag behavior.
The renderer's gaze point is updated exclusively from:
avatar-overlay-computer-use-cursor-changed
That message is populated from computerUseCursorPoint, not from the physical cursor position. The renderer then computes lookFrame from that message's point.
A likely fix is to publish the effective physical cursor point to the same gaze-position path when Computer Use is inactive, while preserving the Computer Use cursor as the override when active.
Activity
WenSilvia commentedon Jul 16, 2026
Confirmed on macOS as well.
Environment:
26.707.91948(build5440)0.144.526.5(25F71), arm64spriteVersionNumber: 2, 1536×2288 WebP, 8×11 cellsThe standard animation rows render correctly, but physical mouse movement does not activate any of the 16 look-direction frames in rows 9–10. This remains reproducible after fully quitting and reopening Codex, keeping the pet idle, and moving the cursor throughout the Codex window outside the expected dead zone.
The atlas and manifest validate correctly, so this appears to be the same physical-pointer-to-gaze input-path issue reported here, rather than a spritesheet problem.
This makes the bug cross-platform: Windows and macOS.
JGSphaela commentedon Jul 18, 2026
I thought this was intentional. Confirm on MacOS on the 144.6
gessnaka commentedon Sep 7, 2026
I can reproduce this on macOS as well, including with the built-in pet.
I investigated the renderer bundle and was able to fix the issue locally. The v2 sprite sheet itself appears to be fine; the problem seems to be how the gaze target is wired.
The renderer receives physical mousemove events, but the gaze calculation does not use the physical mouse position. It currently prioritizes the special/task cursor, caretPoint, and the Computer Use cursor.
I added a physicalCursorPoint state updated from the renderer's existing mousemove events (throttled with requestAnimationFrame) and used it as the final fallback for the gaze target:
const gazeTarget =
specialCursor ??
caretPoint ??
computerUseCursor ??
physicalCursorPoint;
With that change, the v2 look-direction rows immediately started working and the pet correctly follows the physical mouse.
I tested this by patching the current ChatGPT Desktop app locally, repacking app.asar, updating its ASAR integrity hash, and launching the patched build. The same custom pet that did not react to the physical cursor in the unmodified app works correctly after this runtime-only change, with no changes to pet.json or the sprite sheet.
I also tested the patch starting from a clean copy of the app and confirmed the same result.
So this looks like a runtime/input-routing issue rather than a problem with custom pet assets.
If useful, I can provide a minimal diff of the renderer change.
gessnaka commentedon Sep 7, 2026
I investigated this further on the current Windows build (OpenAI.Codex_26.901.6511.0_x64) using a disposable copy of the app.
I confirmed that the renderer's V2 gaze state follows the Computer Use cursor but not the physical mouse. I added a physical mousemove fallback locally, and it works: both my custom V2 pet and the built-in pets start following the physical cursor.
However, this exposed a second reproducible Windows issue:
I reproduced this with both custom and built-in pets, so this does not appear to be an asset/spritesheet issue.
I traced the relevant main-process code to setContentBounds(), applyPointerInteractivityPolicy(), setInputShape(), setIgnoreMouseEvents(...), and the cached mousePassthroughMode.
As an A/B test, I forced supportsInputShape = false. The post-resize failure still occurs, so setInputShape() alone is not the cause.
My current hypothesis is that the final resize invalidates or changes the native Windows passthrough/hit-testing state while mousePassthroughMode still believes the window is already in "forwarding" mode, preventing setIgnoreMouseEvents(true, { forward: true }) from being reapplied. I have not yet confirmed this hypothesis with runtime logs.
So there appear to be two issues:
The first can be fixed at the renderer level; the second currently prevents that fix from remaining functional.
feat(agent-chat): 宠物 V2 —— 自装宠物（<CODEX_HOME>/pets）+ 视线跟随实体鼠标 + 内置三色 P…