[BUG] `prefersReducedMotion: true` freezes the working indicator's elapsed timer until the next keystroke

Reproduced on v2.1.233 (macOS, tmux).

Steps:

1. In a project dir, create .claude/settings.json with {"prefersReducedMotion": true} (also reproduces with "tui": "fullscreen").
2. Start claude, turn fast mode off, set /effort max.
3. Send a prompt that keeps the model thinking for a while with no tool calls, e.g. "Without using any tools, think extremely deeply for as long as you can about whether P = NP, then answer in one line."
4. Watch the (Ns · thinking …) counter without touching the keyboard, then press any key.

Observed: the counter stops advancing while the model is thinking. In one run it sat at (1s · thinking with max effort) for the full 60s of a 1m 9s turn. In another it showed (11s …) at 25s of wall clock; typing one character made it jump straight to (26s …), then it stayed at 26s for the next 8s with no further keys.

--- before keypress (25s wall clock)
● Recalibrating… (11s · thinking with max effort)
--- right after typing one character
● Recalibrating… (26s · thinking more with max effort)
--- 8s later, no keys
● Recalibrating… (26s · thinking more with max effort)

The counter does keep moving when something else on screen is changing (tokens streaming, a running Bash tool updating its own timer), which matches the report: the value is right, it just isn't repainted on its own once reduced motion is on.

Expected: the elapsed-seconds counter keeps ticking about once a second under reduced motion; only the spinner animation and shimmer should be suppressed.

Assessment: this looks like a genuine bug. The docs say prefersReducedMotion "reduces or disables spinners, shimmer, and other animations without changing the rest of the interface", but the elapsed timer is status information, not an animation, and it goes stale because the working indicator only repaints on the animation clock that reduced motion turns off. This is longstanding behavior rather than a recent regression. The fix is to keep a slow (about once per second) repaint for the elapsed counter even when reduced motion is on.

🤖 Generated with Claude Code

Reproduced on the current release (2.1.233), with one narrowing observation.

With "prefersReducedMotion": true and "tui": "fullscreen" (as in your config), the elapsed counter in the working indicator freezes during thinking pauses — I watched it sit at (0s · thinking) for 15+ seconds of real time with no input, then snap to the correct value on the next keystroke, exactly the "value is computed, repaint is missing" shape you described. Toggling prefersReducedMotion back to false live made the same phase tick again.

Two things look better than in 2.1.227, so a partial fix seems to have landed: the counter now ticks during long tool executions even with reduced motion on, and in the default (non-fullscreen) TUI I couldn't reproduce a freeze in any phase. The remaining gap is the fullscreen working indicator during thinking/quiet periods, which matches the frozen Thinking… (36s · …) state in your report.

Agreed on the expectation: elapsed time is state, not decoration, and reduced motion shouldn't stop it updating. Keeping this open for the fullscreen thinking-phase case — in the meantime the default TUI mode keeps a live counter with reduced motion enabled, if that's an acceptable workaround for you.

🤖 Generated with Claude Code

Is it possible to hide the timer entirely when prefersReducedMotion is set to true or through some related setting? I would personally find it useful to not look at the ticker at all.