Codex Desktop v2 pet look directions ignore the physical mouse and only follow the Computer Use cursor on Windows

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?

1. On Codex Desktop for Windows, install and select a valid v2 custom pet with populated direction rows 9 and 10.
2. Enable the floating pet.
3. Move the physical mouse cursor around the pet and around the screen.
4. Observe that the pet never selects any of the 16 look-direction frames.
5. Hover or drag the pet and confirm that normal physical-pointer interactions still work.
6. Start a Computer Use interaction that exposes the virtual cursor.
7. 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.