Repository navigation
Codex App pet overlay falls back to idle during active running/waiting/review states #28995
Description
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.30709build4108 - macOS:
26.5.1build25F80 - 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
idleandrunningrows. - Start a task in Codex Desktop that runs longer than a few seconds.
- Watch the floating pet overlay.
- The pet enters the active
runningrow briefly, then falls back toidleeven 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 columns0-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:
idleloops idlerunningloops running while a task is activewaitingloops waiting while blocked on user input/approvalreviewloops review while in review/inspection state- short reactions such as
waving,jumping, and possiblyfailedcan 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:
#22625covers Codex Desktop not reflecting external CLI sessions.#21902covers reduced-motion causing pets to appear non-animated.#20680covers 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.
Activity
qswang977 commentedon Jun 20, 2026
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 commentedon Jun 29, 2026
I can reproduce this on macOS as well.
Environment:
Observed behavior:
running.idleeven though Codex is still thinking / running tools / updating the activity bubble.idleandrunningrows are visually distinct; both behave the same.Additional debugging:
runningrow is correct.Expected:
running.YutaHasimoto commentedon Jul 14, 2026
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
runningfor approximately 2.46 seconds, then falls back toidleindefinitely.The custom atlas validates successfully (
1536x1872), and row 7 contains all six expectedrunningframes, 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
loopStartIndexto the beginning of that idle segment. Forrunning, 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, andreviewshould continue looping while their corresponding task state remains active, and return toidleonly when the state changes.aubreyhayes47 commentedon Aug 7, 2026
Adding a Windows/custom-pet reproduction that appears to confirm this behavior.
Environment:
Observed:
Additional diagnosis:
runningto row 7 correctly, so this is not a swapped or invalid sprite row.runningonly 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 commentedon Aug 11, 2026
Adding a current Windows reproduction. This issue is still present in Codex App 26.803.10989.0.
Environment:
spriteVersionNumber: 2)Observed:
runninganimation.runningfalls back visually toidleafter approximately 2.46 seconds, while the logical task is still active.idle.Expected:
The
runninganimation should loop for the full active turn and return toidleonly after the task state changes.patriotnate117 commentedon Aug 26, 2026
Confirmed on Codex Desktop for Windows package
OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0with a valid custom v2 Knight DJ pet whoserunningrow 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
runningtiming 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-2568e0345038985ebc882493de0ab8b845fd9c7f9180d23d4732f69452833c83f25). The behavioral change is:The proof-of-concept tests confirm that:
runningloops its own frames from index zero;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.
junweili-cmd commentedon Sep 5, 2026
Adding a current macOS check and a native preference request: Codex Desktop 26.901.41600 (build 7982), Apple Silicon, using a custom v2 pet.
Read-only inspection of the current packaged renderer and isolated execution of its frame-selection function confirm that the same three-cycle-then-idle policy remains present. The current frame data gives fallback times of approximately 2.46 s for running, 3.03 s for waiting, and 3.09 s for review. These are computed timings, not a fresh stopwatch measurement of the live UI. Whether a state is selected at all is separate from its playback duration.
Please consider an opt-in preference such as “Loop Pet animations while their state is active.” It should reuse the native Pet window, assets, and state selection, and loop the corresponding animation until the actual state changes. My preference is for this to cover all non-idle states, including failed, waving, jumping, and left/right running whenever the controller continues to hold those states; it should not extend a transient state beyond its actual lifetime.
Suggested acceptance criteria:
I have previously used a local bundle patch to get the looping behavior, but maintaining it requires repeated update-time reapplication and can invalidate macOS code signatures. Native support would avoid that maintenance and the need to build a separate companion app. This is a request for the animation option itself; failures caused by unofficial patches should not be interpreted as evidence of a stock updater/signing bug.
Lizst777 commentedon Sep 24, 2026
Adding a current Windows reproduction with a validated custom v2 pet (Nocturne).
26.917.71314(build10954, production channel, up to date). The running Windows package path isOpenAI.Codex_26.917.9434.0_x64.custom:nocturne; manifest hasspriteVersionNumber: 2.runningto row 7 but plays a non-idle row three times, then loops an appended idle tail. At the current frame durations this is about 2.46 seconds of working animation before the pet looks idle, even when the task is still active.runningstate at all. This overlaps with Automatically track the highest-priority active task with desktop pets #32994.Expected: the pet should show and loop the
runningrow for the full lifetime of an active task, including the currently open task, and return to idle when that state ends. No user session transcript, logs, or local file paths are attached.Sun-Lebs-For-DeepOM commentedon Oct 26, 2026
Windows package 26.1013.4894.0: my custom pet returns to idle while the task is still running. Read-only local inspection found that the sprite player has a loop parameter defaulting to false, but the floating-pet wrapper does not enable it. The running animation therefore plays three cycles (about 2.46 seconds, calculated from frame timings) before returning to idle. No client patch was applied. Please keep the running animation active until the task state changes, or provide a supported loop preference.