Codex App pet overlay falls back to idle during active running/waiting/review states

Open 💬 6 comments Opened Jun 18, 2026 by shaharyarmaroof-em

What version of the Codex App are you using (From “About Codex” dialog)?

26.616.30709 build 4108

What subscription do you have?

ChatGPT plan, exact tier can be filled by reporter

What platform is your computer?

macOS 26.5.1 build 25F80, Apple Silicon / arm64

What issue are you seeing?

In Codex Desktop, the floating pet/avatar overlay does not stay in the active animation state while a task is still running. A custom Codex pet with distinct idle and running rows initially switches to the running row, but after a short burst it falls back to the idle row even though the task is still active.

This makes the pet visually report "idle" during long-running work and removes the distinction between idle and active task states.

Environment observed:

Codex App: 26.616.30709 build 4108
macOS: 26.5.1 build 25F80
Architecture: Apple Silicon / arm64
Runtime: desktop app pet/avatar overlay

What steps can reproduce the bug?

Install or select a Codex pet whose atlas has visibly distinct idle and running rows.
Start a task in Codex Desktop that runs longer than a few seconds.
Watch the floating pet overlay.
The pet enters the active running row briefly, then falls back to idle even while the task continues.

I reproduced this with a custom pet package under:

~/.codex/pets/slifer-sky-dragon/
├── pet.json
└── spritesheet.webp

The atlas validates against the current custom pet contract:

size: 1536x1872
grid: 8 columns x 9 rows
row 7 running: non-empty columns 0-5
row 0 idle: distinct calm idle animation

Root-cause evidence from the packaged desktop bundle:

The bundled avatar player maps every non-idle state to three cycles of that state followed by the slowed idle loop:

function w(e,t){
  let n=S[e];
  if(t)return{frames:[n[0]],loopStartIndex:null};
  if(e===`idle`)return{frames:x,loopStartIndex:0};
  let r=[...n,...n,...n];
  return{frames:[...r,...x],loopStartIndex:r.length}
}

Because running, waiting, and review are persistent semantic states, this makes them behave like temporary reactions.

What is the expected behavior?

Persistent pet states should loop their own rows until the session/activity state changes:

idle loops idle
running loops running while a task is active
waiting loops waiting while blocked on user input/approval
review loops review while in review/inspection state
short reactions such as waving, jumping, and possibly failed can continue to fall back to idle

The local fix that validated the behavior was:

function w(e,t){
  let n=S[e];
  if(t)return{frames:[n[0]],loopStartIndex:null};
  if(e===`idle`)return{frames:x,loopStartIndex:0};
  if(e===`running`||e===`waiting`||e===`review`)return{frames:n,loopStartIndex:0};
  let r=[...n,...n,...n];
  return{frames:[...r,...x],loopStartIndex:r.length}
}

After applying this locally to the packaged app bundle and restarting Codex, a 45-second test task kept the pet in the running animation for the duration instead of falling back to idle.

Additional information

Related public issue search found pet/avatar overlay issues, but not this exact state-looping bug:

#22625 covers Codex Desktop not reflecting external CLI sessions.
#21902 covers reduced-motion causing pets to appear non-animated.
#20680 covers pet overlay renderer/GPU load.

This issue is specifically about the animation playback policy for persistent avatar states once the app has already selected the correct state.

View original on GitHub ↗

6 Comments

qswang977 · 2 months ago

I can reproduce this on Windows as well.

Environment:
Codex Desktop 26.616.5445.0
Windows

This affects both built-in pets and custom pets. During an active task, the pet briefly switches to running and then falls back to idle after a few seconds. After task completion, the review/OK state also only appears briefly and then falls back to idle.

Feedback ID from Codex Desktop:
019ed38b-393f-7c32-85f2-fa10ae0c3452

Somnusochi · 2 months ago

I can reproduce this on macOS as well.

Environment:

Codex Desktop: 26.623.61825
macOS, Apple Silicon
Both built-in pets and custom pets are affected

Observed behavior:

When a task starts, the pet briefly switches to running.
After a short time, it falls back to idle even though Codex is still thinking / running tools / updating the activity bubble.
I tested with the built-in Codex pet and with a custom pet whose idle and running rows are visually distinct; both behave the same.

Additional debugging:

The custom pet atlas validates and the running row is correct.
Since the built-in Codex pet reproduces too, this does not appear to be a custom pet packaging issue.
Inspecting the local desktop bundle suggests non-idle states are played as a finite prelude and then idle frames are appended/looped, which matches the observed behavior.

Expected:

While Codex has an active running task/session, the pet should remain in running.
Waiting/review/failed states should remain visible while those states are active.

YutaHasimoto · 1 month ago

I can reproduce this on macOS with Codex Desktop 26.707.72221 (build 5307).

While the task remains active—the task UI still shows “working” and the activity bubble continues updating—the pet switches to running for approximately 2.46 seconds, then falls back to idle indefinitely.

The custom atlas validates successfully (1536x1872), and row 7 contains all six expected running frames, so this is not missing or malformed artwork.

In this build, the packaged animator repeats a non-idle row three times, appends the slowed idle frames, and sets loopStartIndex to the beginning of that idle segment. For running, this is approximately (5 × 120ms + 220ms) × 3 = 2.46s, after which only idle frames loop even though the task remains active.

Expected behavior: running, waiting, and review should continue looping while their corresponding task state remains active, and return to idle only when the state changes.

aubreyhayes47 · 20 days ago

Adding a Windows/custom-pet reproduction that appears to confirm this behavior.

Environment:

Codex Windows desktop package: 26.730.8199.0
Custom pet: Fae, v2 atlas (1536×2288 WebP)
Atlas validation: passes the v2 contract; row 0 is a distinct idle/sleep animation and row 7 is a distinct running/work animation.

Observed:

During an active turn, Fae spends most of the time showing the idle/falling-asleep animation.
The working animation appears only briefly, typically during short loading activity.

Additional diagnosis:

The packaged renderer maps running to row 7 correctly, so this is not a swapped or invalid sprite row.
The player gives persistent non-idle states a finite active sequence before appending the idle loop; the activity mapping also marks running only for loading notifications. This allows the pet to return to idle while the turn is still active.

Expected behavior: the running row should loop for the full active turn and return to idle only when the turn actually leaves the running state. This reproduces with a valid custom v2 pet and supports the proposed fix in this issue.

Korotarou · 17 days ago

Adding a current Windows reproduction. This issue is still present in Codex App 26.803.10989.0.

Environment:

Windows x64
Codex App 26.803.10989.0
Custom v2 pet (spriteVersionNumber: 2)

Observed:

When a task starts, the pet briefly enters the running animation.
In my environment, running falls back visually to idle after approximately 2.46 seconds, while the logical task is still active.
While Codex is still actively working, the pet remains visually in idle.
The pet animation therefore no longer reflects the actual task state.

Expected:

The running animation should loop for the full active turn and return to idle only after the task state changes.

patriotnate117 · 1 day ago

Confirmed on Codex Desktop for Windows package OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0 with a valid custom v2 Knight DJ pet whose running row is a visibly distinct mixing animation.

The current packaged renderer still contains the same playback policy described in this issue: every non-idle state is repeated three times and then given a looping idle tail. With the current six-frame running timing table, that makes the working animation last about 2.46 seconds before the pet looks idle while the chat remains active.

I built and tested a version-locked minimal transform against webview/assets/codex-pet-assets-3PPKE7db.js (original SHA-256 8e0345038985ebc882493de0ab8b845fd9c7f9180d23d4732f69452833c83f25). The behavioral change is:

if (state === "running") {
  return { frames: runningFrames, loopStartIndex: 0 };
}

The proof-of-concept tests confirm that:

running loops its own frames from index zero;
reduced motion still uses one static frame;
idle and non-running state behavior remain unchanged;
the transform is idempotent and refuses unknown renderer layouts.

This corroborates the issue on the current Windows build. The desired upstream behavior is for the running animation to remain active until the semantic task state changes, while continuing to respect reduced-motion settings.