Terminal animations use excessive terminal output

What version of Codex CLI is running?

Current HEAD (85034b18; 2026-02-14 19:57:10 -0800)

What subscription do you have?

pro

Which model were you using?

gpt-5.3-codex high

What platform is your computer?

Linux 6.18.8-arch2-1 x86_64 unknown

What terminal emulator and version are you using (if applicable)?

Suckless terminal, tmux 3.6a

What issue are you seeing?

When Codex shows the StatusIndicatorWidget animation (i.e. "Working", "Searching for running animation terms", "Checking current git status"), it writes far more terminal bytes than needed. Some of the inefficiencies, if fixed, help all TUI redraws and shimmers, giving more benefits than just for StatusIndicatorWidget.

These inefficiencies cause two issues:

1. Raw PTY output is much higher than needed. The unnecessary terminal I/O increases CPU usage, battery drain, and adds terminal/multiplexer overhead.
2. In tmux, the redraw pattern grows the in-memory size of terminal history very quickly (~139 KB/s.) Even if that's not triggered for days at 11 GB/day, like I discussed in issue #11857, this is still the equivalent of a very large memory leak when Codex runs within tmux. (It is released if the pane closes.)

Measured results from investigation and after proof-of-concept fixes while a StatusIndicatorWidget animation is being rendered:

• Raw terminal writes (observed using script -f):
• Before: 10.72 KB/s
• After latest proof-of-concept patches: 3.48 KB/s
• Reduction: 67.53%
• tmux history growth (history_bytes):
• Before: about 139 KB/s (this can be much larger than 10.72 KB/s in raw writes because history_bytes is tmux internal history storage growth, not raw PTY write bytes)
• After fixes: 0 B/s
• (Codex says the thrashing clear to end of line sequences currently used cause lots of tmux history usage, but the proof of concept fixes makes it efficiently overwrite the same area.)

It's quite possible this causes other multiplexers or terminals to substantially grow in usage. My terminal (suckless) by default doesn't have scrollback.

What steps can reproduce the bug?

Path A: Raw terminal write rate (without tmux)

1. Run:

• script -q -f /tmp/raw.log -c 'codex --no-alt-screen -a never -s workspace-write "Run exactly one shell command: sleep 300. Set timeout_ms to 360000. Execute it now and remain idle until it completes. Do not ask for confirmation."'

1. Wait until Codex shows the running state (for example Running sleep 300).
2. Sample raw output growth once per second:

• stat -c%s /tmp/raw.log

Path B: tmux history growth (history_bytes)

1. Start a tmux session/pane.
2. Run that same Codex command in the tmux pane:

• codex --no-alt-screen -a never -s workspace-write "Run exactly one shell command: sleep 300. Set timeout_ms to 360000. Execute it now and remain idle until it completes. Do not ask for confirmation."

1. Wait until Codex shows the running state.
2. Sample tmux history_bytes growth once per second:

• tmux list-panes -t <pane> -F 'hist_bytes=#{history_bytes} hist_lines=#{history_size}'

What is the expected behavior?

Without changing the appearance of animations:

• Avoid unnecessary redraw/clear traffic on unchanged terminal characters.
• Reduce tmux history_bytes growth from 139 KB/s to 0 B/s.

Additional information

Simple explanation of "before vs after":

• Before: Codex frequently moved the cursor and emitted extra clear/style updates beyond what the user could visually notice.
• After: Codex still animates the same, but sends fewer unnecessary terminal commands.

Proof-of-concept patches

Codex isn't generally accepting external PRs. These commits are provided as proof-of-concept, for your instance of Codex to loosely consider, or actual integration into Codex. I have a CLA signature on record (commit 99f38c14) and will submit a formal PR if requested.

Branch used: darlingm:fix/tui-reduce-running-animation-terminal-throughput

Commits:

1. 5100186806 - avoid per-row clear-to-end churn in diff renderer (CPU cost: low; adds row-level checks, but usually far cheaper than the terminal I/O it removes)
2. 68a78a9867 - skip redundant cursor and terminal reset writes (CPU cost: negligible; mostly simple equality checks before emitting commands)
3. 04311fc863 - batch contiguous same-style cell prints (CPU cost: low; linear scan/merge logic with less write overhead)
4. 25fd222144 - reduce animation redraw and color command overhead (CPU cost: low; some scheduling/time math, but fewer redraws and fewer escape writes overall)
5. 2db3fc8bf3 - avoid animating whitespace shimmer cells (CPU cost: negligible to positive; tiny branch that skips unnecessary style work)

Measured progression (raw PTY):

• Before patches: 10.72 KB/s
• After (1): 6.02 KB/s
• After (1+2+3): 4.81 KB/s
• After (1+2+3+4): 4.20 KB/s
• After (1+2+3+4+5): 3.48 KB/s

Measured progression (tmux history_bytes):

• Original thrash baseline: ~139 KB/s (higher than raw 10.72 KB/s because it is tmux history storage growth rather than PTY wire bytes)
• After (1): 0 B/s
• After (1+2+3+4+5): 0 B/s

Why continue reducing raw PTY output after tmux history_bytes is zero? (Why use patches 2-5?)

• Raw PTY bytes still represent real terminal traffic.
• Lower raw PTY traffic can still improve CPU usage, reduce battery drain, reduce terminal/multiplexer overhead, and improve responsiveness in remote/SSH sessions.
• In short: fixing tmux history_bytes growth solves one major symptom; reducing raw PTY throughput improves general runtime efficiency.