Support persistent lifecycle state for custom pets

Open 💬 0 comments Opened Jun 25, 2026 by Zhiming-Huang

What feature would you like to see?

Please consider adding a supported lifecycle/progression API for Codex custom pets.

Current custom pets are mainly visual assets: pet.json points to a spritesheet, and the app runtime owns the animation states. This works for visual customization, but it does not allow pet creators to build progression-style pets.

A useful extension would be a small, permissioned pet state model that supports lifecycle stages such as:

  • egg
  • hatching
  • baby
  • grown

and user interactions such as:

  • feed
  • play
  • rest
  • hatch
  • evolve/grow

Example use case

A custom pet could start as an egg. After enough time, user interaction, or Codex activity, it hatches. The user can feed it, and its persistent state changes over time:

{
  "stage": "egg",
  "xp": 12,
  "hunger": 40,
  "mood": "happy",
  "lastFedAt": "2026-06-24T12:00:00Z"
}

The pet runtime could map this state to existing or custom animation states:

  • egg_idle
  • hatching
  • hungry
  • eating
  • happy
  • sleeping
  • grown_idle

Why this matters

The Hatch Pet workflow can already generate expressive pet assets, but custom pets remain mostly static/status-driven unless the Codex app exposes runtime behavior. Lifecycle state would make pets feel more alive while still keeping the API safe and constrained.

This is related to, but distinct from:

  • #20863, which asks for configurable animation sequences and activity events.
  • #21657, which asks for interaction hooks and APIs.

This request is specifically about persistent per-pet lifecycle/progression state.

Compatibility

This could be additive:

  • Existing pets keep working unchanged.
  • Pets without lifecycle config remain visual/status pets.
  • Lifecycle state could be opt-in through a new lifecycle or state section in pet.json.
  • The app should remain the authority for storage, permissions, and safety.

View original on GitHub ↗