## Summary Codex Desktop pets currently evade the pointer when the user approaches them. This makes it difficult to click, grab, or reposition the pet, and turns a companion into something the user has to chase. Please add two explicit interaction modes: 1. **Stay** — the pet remains in place when the pointer approaches. This should be the default. 2. **Draggable** — the pet can be clicked and dragged directly without first triggering flee or movement behavior. ## Why these two modes A pet

Feature request: Add Stay and Draggable modes for Codex pets

Open 💬 2 comments Opened Jul 11, 2026 by Crystal32378

Summary

Codex Desktop pets currently evade the pointer when the user approaches them. This makes it difficult to click, grab, or reposition the pet, and turns a companion into something the user has to chase.

Please add two explicit interaction modes:

Stay — the pet remains in place when the pointer approaches. This should be the default.
Draggable — the pet can be clicked and dragged directly without first triggering flee or movement behavior.

Why these two modes

A pet is primarily a companion and status indicator. It should remain reachable and should not block basic interaction.

The current flee-on-hover behavior causes several problems:

the pet disappears or moves before the user can grab it
repositioning becomes frustrating and unpredictable
users may interpret the behavior as a rendering bug
directional animations can be triggered when the user only intended to drag the pet
the interaction is especially confusing for custom pets with incomplete directional rows

Even with a complete spritesheet, mandatory evasion is still undesirable for users who want a calm desktop companion.

Expected behavior

Stay

pointer approach does not trigger movement
pet continues its current state animation
clicking or hovering does not make it flee
suitable as the default interaction mode

Draggable

pointer down immediately captures the pet
drag begins without triggering move_left, move_right, running-left, or running-right
releasing the pointer places the pet at the new position
no evasive animation occurs before or during drag

Suggested setting

A per-user or per-pet setting such as:

Pet interaction
- Stay (default)
- Draggable

These two modes are enough for users who want the pet to behave as a stable companion rather than a mini-game.

A companion should be reachable. The user should not have to chase it in order to move it.

View original on GitHub ↗

2 Comments

Crystal32378 · 1 month ago

Additional runtime evidence from a custom pet:

running-left is now populated and displays correctly.
running-right is populated and displays correctly.
Pointer approach triggers the expected left/right movement animations.
On actual pointer-down / grab, the pet still becomes invisible.

This rules out missing directional rows as the explanation for the disappearance. It may be a separate grab/drag state selecting another animation row, or App-level overlay behavior during pointer capture.

A full spritesheet test will help distinguish those cases, but the interaction problem remains: the user cannot reliably grab and reposition the pet. This supports the need for a true Draggable mode where pointer-down captures the pet immediately without switching animation state first.

Crystal32378 · 1 month ago

Additional runtime evidence from a custom pet on macOS:

running-left and running-right rows are both present and render correctly.
The app was fully quit and reopened twice after updating the pet package.
Hover/evasion animations work in both directions.
The pet still becomes invisible specifically when the user tries to grab/drag it.

This strongly suggests the disappearance is not caused by missing directional frames or stale app state. It appears to be App-level pointer-down / drag behavior in the desktop pet overlay.

Requested behavior remains:

Stay as the default
direct Draggable interaction without hiding or fleeing

A visible companion should remain visible when the user grabs it.