Codex Desktop pets do not animate when macOS ReduceMotionEnabled is set

What variant of Codex are you using?

Codex App / Codex Desktop on macOS.

What issue are you seeing?

All Codex Desktop pets can appear broken/non-animated when macOS reduced motion is enabled through com.apple.Accessibility ReduceMotionEnabled.

The pet/avatar renderer appears to read window.matchMedia('(prefers-reduced-motion)'). When that media query is true, the pet component only displays the first frame instead of advancing animation frames. This makes every built-in pet look like it is stuck on a single frame, especially on hover.

This is confusing because disabling only the commonly checked preference did not fix it:

defaults write com.apple.universalaccess reduceMotion -bool false

The actual remaining preference that kept prefers-reduced-motion true was:

com.apple.Accessibility ReduceMotionEnabled = 1

After disabling both preferences and restarting/remounting the Codex renderer, built-in pets animated normally again:

defaults write com.apple.universalaccess reduceMotion -bool false
defaults write com.apple.Accessibility ReduceMotionEnabled -bool false
killall cfprefsd

Confirmed state afterward:

Accessibility ReduceMotionEnabled=0

Steps to reproduce

1. On macOS, enable the reduced-motion preference such that this value is set:

``bash
defaults read com.apple.Accessibility ReduceMotionEnabled
# 1
``

1. Open Codex Desktop.
2. Wake the desktop pet with /pet.
3. Select any built-in pet.
4. Move the mouse over the pet or observe its idle animation.

Expected behavior

Either:

• pets animate normally when system reduced motion is disabled, or
• if reduced motion is enabled, Codex makes it clear that pet animation is intentionally disabled because of the OS accessibility preference.

Also, after the OS preference is changed, the pet overlay should eventually pick up the new value or provide a way to remount/reload the overlay.

Actual behavior

All built-in pets appear to be stuck on a single frame. On hover, the pet appears to switch to one hover/active frame but does not animate.

The problem persists until the relevant macOS preference is disabled and the Codex renderer / pet overlay is restarted or remounted. The value appears to be read when the frontend component mounts, so an already-open Codex renderer may not refresh immediately after defaults changes.

Workaround

Run:

defaults write com.apple.universalaccess reduceMotion -bool false
defaults write com.apple.Accessibility ReduceMotionEnabled -bool false
killall cfprefsd

Then restart Codex Desktop or otherwise cause the pet overlay/renderer to remount.

Why this is worth tracking

This looks like an intentional reduced-motion behavior, but it is difficult to diagnose because:

• all built-in pets look broken, not just custom pets;
• checking only com.apple.universalaccess reduceMotion may show reduced motion as disabled;
• com.apple.Accessibility ReduceMotionEnabled can still keep prefers-reduced-motion true;
• changing the preference may not affect an already-mounted Codex renderer immediately.

A small docs note, diagnostics hint, or renderer refresh behavior would make this much easier to understand.

Related issues searched

I did not find an exact duplicate. Related but distinct issues include:

• #20863: custom pet animation configuration; this issue affects built-in pets too.
• #20680 / #16099: animation/GPU overhead; those are about reducing animation cost, while this is about reduced-motion disabling pet animation in a non-obvious way.
• #20828 and other pet overlay rendering issues: related pet rendering area, but not the same root cause.