Feature request: configurable Codex pet animation duration

Feature request

Please consider adding configurable animation behavior for Codex pets, especially for the built-in pet states shown in the floating overlay.

Motivation

The built-in pet animations are delightful and also useful as lightweight status indicators. For example, the Seedy pet's running/working-at-laptop animation clearly communicates that Codex is actively working. Currently, the non-idle animation appears briefly and then returns to the idle loop, even when Codex is still running.

It would be helpful if users could configure how long non-idle pet animations remain visible, or optionally keep the running/working animation active while Codex is still working.

Possible behavior

Keep the running/working animation visible for as long as Codex is actively running.
Let users adjust how long non-idle pet animations play before returning to idle.
Optionally let users choose a preferred idle or working animation for built-in pets.
Respect reduced-motion settings, so users who prefer less animation can keep the current or a simplified behavior.

Why this helps

This would make the floating pet overlay more expressive and useful. Users could glance at the pet and immediately understand that Codex is still working, without reopening the main window or checking the thread status.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Codex App pet overlay falls back to idle during active running/waiting/review states #28995
Codex Desktop pet animation falls back to idle while task is still running #29196

Powered by Codex Action

Implemented a focused patch for this in my fork:

Branch: Nicolas0315:codex/pet-status-animation-duration
Commit: 6c5b5b2d92fc7107ff7b28ca4287c7b74e3195f7
Compare: https://github.com/openai/codex/compare/main...Nicolas0315:codex/pet-status-animation-duration?expand=1

What changed:

Added [tui] pet_status_animation_duration_seconds to let users keep non-idle pet status animations playing longer before returning to idle.
The default/omitted value, and 0, preserve current built-in timing.
animations = false still uses the stable first frame and schedules no follow-up animation frames.
Regenerated codex-rs/core/config.schema.json.

Local verification:

just fmt
just write-config-schema
git diff --check
cargo test --manifest-path codex-rs\Cargo.toml -p codex-tui status_animation -- --nocapture
cargo test --manifest-path codex-rs\Cargo.toml -p codex-tui reduced_motion_uses_stable_first_frame_and_schedules_no_follow_up -- --nocapture
cargo check --manifest-path codex-rs\Cargo.toml -p codex-config
cargo check --manifest-path codex-rs\Cargo.toml -p codex-core -p codex-tui

SSH validation:

cyberagent-mac-m5max: checked out exact commit, git diff --check OK, focused TUI tests OK, cargo check -p codex-core -p codex-tui OK.
nicolas2025: checked out exact commit, git diff --check OK, focused TUI tests OK, cargo check -p codex-core -p codex-tui OK, no lingering cargo/rustc/link processes.
nicolas-macbook-pro: checked out exact commit, git diff --check OK; Rust toolchain unavailable on this host, so diff-only.
rtx5060ti: checked out exact commit, git diff --check OK; cargo is still blocked by the host's existing linker mismatch (link: extra operand ..., exit 101), no lingering cargo/rustc/link processes.

One boundary: cargo test -p codex-core pet_status_animation_duration is currently blocked before reaching these tests by an unrelated existing compile error in core/src/session/tests.rs where a CreateThreadParams literal is missing history_mode.

Merge-tree against current origin/main (1168254bd) is clean; I left the validated commit unre-based.

Thanks a lot for taking the time to implement this! I really appreciate your effort. I’m not very familiar with the codebase myself — I originally just wanted to customize the Codex pet a bit with Codex’s help — but your patch looks very thoughtful and well-tested to me. I hope it can provide a useful reference or idea for the maintainers if they decide to support this officially. Thanks again, and best wishes!

…

---Original--- From: ***@***.***> Date: Sat, Jun 27, 2026 06:19 AM To: ***@***.***>; Cc: "Yang ***@***.******@***.***>; Subject: Re: [openai/codex] Feature request: configurable Codex pet animation duration (Issue #30268) Nicolas0315 left a comment (openai/codex#30268) Implemented a focused patch for this in my fork: Branch: Nicolas0315:codex/pet-status-animation-duration Commit: 6c5b5b2 Compare: https://github.com/openai/codex/compare/main...Nicolas0315:codex/pet-status-animation-duration?expand=1 What changed: Added [tui] pet_status_animation_duration_seconds to let users keep non-idle pet status animations playing longer before returning to idle. The default/omitted value, and 0, preserve current built-in timing. animations = false still uses the stable first frame and schedules no follow-up animation frames. Regenerated codex-rs/core/config.schema.json. Local verification: just fmt just write-config-schema git diff --check cargo test --manifest-path codex-rs\Cargo.toml -p codex-tui status_animation -- --nocapture cargo test --manifest-path codex-rs\Cargo.toml -p codex-tui reduced_motion_uses_stable_first_frame_and_schedules_no_follow_up -- --nocapture cargo check --manifest-path codex-rs\Cargo.toml -p codex-config cargo check --manifest-path codex-rs\Cargo.toml -p codex-core -p codex-tui SSH validation: cyberagent-mac-m5max: checked out exact commit, git diff --check OK, focused TUI tests OK, cargo check -p codex-core -p codex-tui OK. nicolas2025: checked out exact commit, git diff --check OK, focused TUI tests OK, cargo check -p codex-core -p codex-tui OK, no lingering cargo/rustc/link processes. nicolas-macbook-pro: checked out exact commit, git diff --check OK; Rust toolchain unavailable on this host, so diff-only. rtx5060ti: checked out exact commit, git diff --check OK; cargo is still blocked by the host's existing linker mismatch (link: extra operand ..., exit 101), no lingering cargo/rustc/link processes. One boundary: cargo test -p codex-core pet_status_animation_duration is currently blocked before reaching these tests by an unrelated existing compile error in core/src/session/tests.rs where a CreateThreadParams literal is missing history_mode. Merge-tree against current origin/main (1168254) is clean; I left the validated commit unre-based. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

I can reproduce the underlying behavior that motivated this request as well.

Environment:

Codex Desktop: 26.623.61825
macOS, Apple Silicon

The non-idle animation is useful as a status indicator, but currently both built-in and custom pets briefly enter running and then fall back to idle while Codex is still working. Configurable duration would help, but I think the baseline behavior should be that running, waiting, review, and failed remain visible while the corresponding Codex state is active.

Related bug reports: #28995 and #23272.

Navigation Menu

Repository navigation

Feature request: configurable Codex pet animation duration #30268

Feature request

Motivation

Possible behavior

Why this helps

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature request: configurable Codex pet animation duration #30268

Description

Feature request

Motivation

Possible behavior

Why this helps

Activity

github-actions commented on Jun 26, 2026

Nicolas0315 commented on Jun 26, 2026

3ooowe commented on Jun 27, 2026

Somnusochi commented on Jun 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions