[macOS][Pets] Pet returns to Idle while assistant is still thinking/streaming

What issue are you seeing?

Codex Pets briefly switch to the Running animation when a task starts, but then return to Idle while the assistant is still thinking or streaming a response.

This happens with a custom v2 pet. The pet itself appears valid: row 7 contains the intended Running/working animation, and the pet briefly shows that animation immediately after submitting a prompt. A moment later, while the assistant is still generating/thinking, the pet returns to the Idle animation.

Observed behavior:

• Submit a message in Codex.
• The pet briefly switches to Running.
• While the assistant is still thinking/streaming, the pet returns to Idle.
• The pet only shows Running again briefly around command/tool activity.

This appears to be an avatar overlay state mapping issue rather than a custom pet asset issue.

What steps can reproduce the bug?

1. Use the ChatGPT/Codex desktop app on macOS.
2. Select any Codex pet with a visible Running animation. In my case, I used a custom v2 pet with spriteVersionNumber: 2.
3. Submit a prompt that takes long enough for the assistant to think or stream a response.
4. Watch the floating pet/avatar overlay while the assistant is still generating.

Result:
The pet briefly enters Running, then returns to Idle before the assistant response has finished.

What is the expected behavior?

The pet should remain in the Running state from the moment a chat/task starts working until the assistant finishes generating the response.

After the assistant finishes, the pet can return to Idle.

In other words, assistant thinking/streaming should count as active work for the pet animation state, not only short command/tool phases.

Additional information

Environment:

• macOS
• ChatGPT/Codex desktop app
• App version: 26.810.52044
• Custom pet: spriteVersionNumber: 2
• Selected avatar: custom:xiaomanpeng-working

The custom pet has a valid row 7 Running animation. The issue appears to be that the avatar overlay only treats a short loading/tool phase as Running, instead of keeping Running active for the whole assistant generation/streaming lifecycle.

Related issue found while searching:
https://github.com/openai/codex/issues/20863