Codex Desktop pet active animations play once, then fall back to idle

I have this issue with built-in pets too, not just the custom ones. Also, I don't think I've ever seen other states besides idle and running - run right, run left, waving, jumping, failed, waiting, review. I'm using Codex CLI.

I had a look at the current Codex Desktop app bundle to narrow down where this seems to come from.

In the desktop webview bundle, the avatar animation helper appears to hardcode active states as a finite prelude followed by an idle loop. In the minified bundle this is in the pet/avatar code, roughly equivalent to:

function getAnimation(state, reducedMotion) {
  const frames = animations[state];

  if (reducedMotion) {
    return { frames: [frames[0]], loopStartIndex: null };
  }

  if (state === "idle") {
    return { frames: slowIdleFrames, loopStartIndex: 0 };
  }

  const activePrelude = [...frames, ...frames, ...frames];
  return {
    frames: [...activePrelude, ...slowIdleFrames],
    loopStartIndex: activePrelude.length,
  };
}

So for any non-idle state (running, waiting, review, failed, etc.), Desktop intentionally plays the active animation for a finite segment, then loops idle. That seems to explain why the pet falls back to idle even while the app/session state is still active.

A likely fix would be to make sustained states loop their own row while that state is still current, for example:

if (state === "idle") {
  return { frames: slowIdleFrames, loopStartIndex: 0 };
}

return {
  frames,
  loopStartIndex: 0,
};

Or, if some states are intended to be one-shot/transient, split the policy explicitly:

const loopingStates = new Set([
  "running",
  "running-left",
  "running-right",
  "waiting",
  "review",
  "failed",
]);

if (loopingStates.has(state)) {
  return { frames, loopStartIndex: 0 };
}

// one-shot states can still transition back to idle
const prelude = frames;
return { frames: [...prelude, ...slowIdleFrames], loopStartIndex: prelude.length };

The important bit is that Desktop currently decides to fall back to idle inside the animation sequence itself, instead of letting the current app state determine when to switch back to idle.

I’m seeing a similar issue on the latest Codex app for macOS.

In my case, when Codex starts a task, the pet’s active animation plays three times and then falls back to idle, even though the task is still in progress.

I also found another way to reproduce it: while Codex is working, hover over the pet, then move the cursor away. The active animation plays three times and then falls back to idle again.

This happens with both the built-in/default pets and custom pets.

I was also able to reproduce what may be a related behavior in the Codex mobile bubble in the latest ChatGPT app for Android. When I start a Codex task, the animation plays either once or three times, then gets stuck on the first frame of the review state. So this may not be limited to desktop.

Environment:

• Codex app: 26.602.40724
• macOS: Tahoe 26.5
• ChatGPT for Android: 1.2026.153 (23)

Same issue in the Windows desktop app (just installed it today so it should be the latest version)

I can also reproduce this on macOS with the current app.

Environment:

• Codex Desktop: 26.623.61825
• macOS, Apple Silicon

This is not limited to custom pets. I tested both the built-in Codex pet and a custom pet with clearly distinct idle and running rows. In both cases the active animation plays briefly, then the pet falls back to idle while Codex is still actively working.

I also inspected the local desktop bundle and the behavior seems consistent with the animation helper playing non-idle state frames as a finite prelude, then appending/looping idle frames. So the package/atlas itself appears valid; the issue looks like desktop overlay animation/state handling.

I can also reproduce this on macOS with Codex Desktop 26.715.31925.

While a task is still actively running, the Pet sometimes appears idle. If I hover over the Pet, the working animation starts and plays for a few seconds. After I move the pointer away, it falls back to idle even though the task is still running.

This matches the finite active-animation sequence followed by the idle loop described in this issue.