macOS VoiceOver regression in 0.154.0: repeated output fragments; disabling animations restores usability

[Deon588]

What version of Codex CLI is running?

codex-cli 0.154.0

What subscription do you have?

ChatGPT Pro ($200)

Which model were you using?

GPT 6 Astra

What platform is your computer?

Mac OS Darwin 25.6.0 arm64 arm

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

Tested on Mac OS Terminal and iTerm 2

Codex doctor report

What issue are you seeing?

This is an accessibility regression affecting macOS VoiceOver after updating Codex CLI from 0.153.4 to 0.154.0.

Before the update, Codex CLI was usable with VoiceOver in my normal workflow. After updating, VoiceOver began continually announcing fragments of terminal output, making interactive use effectively unusable.

The repeated fragment announcements interfere with reading meaningful output and using Codex normally. I rely on VoiceOver for software development, so this is a functional accessibility blocker, not a cosmetic issue.

I confirmed that disabling terminal animations alone restores usability on the updated version:

codex -c tui.animations=false

I initially tested with both tui.animations=false and tui.whimsy=false. I then removed the whimsy override, leaving only tui.animations=false, and VoiceOver continued to work correctly.

Therefore, explicitly disabling tui.whimsy is not required for the workaround in my environment.

What steps can reproduce the bug?

1. Enable macOS VoiceOver.
2. Launch Codex CLI 0.154.0 in the terminal application listed above, with animations enabled.
3. Use an interactive Codex session and ask it to perform a task that produces output.
4. Attempt to read and navigate the terminal output with VoiceOver.
5. Observe that VoiceOver repeatedly announces fragments of output, making normal use effectively unusable.

Workaround comparison:

6. Exit Codex and relaunch it in the same terminal using:
   codex -c tui.animations=false
7. Keep the same model and otherwise use the same workflow.
8. Observe that VoiceOver usability is restored.

Confirmed configuration tests:

• After the update, without the workaround: repeated output-fragment announcements make Codex effectively unusable.
• With tui.animations=false and tui.whimsy=false: usability is restored.
• After removing the tui.whimsy=false override and keeping only tui.animations=false: usability remains restored.

The workflow was usable before the update. I have not performed a rollback comparison.

What is the expected behavior?

Codex CLI should remain usable with macOS VoiceOver after an update.

Visual animations and decorative redraws should not cause repeated announcements of output fragments that interrupt meaningful content or prevent normal screen-reader navigation.

Users should be able to read and review terminal output while Codex is working, without having to mute VoiceOver or wait for all activity to stop.

The existing tui.animations=false setting provides a working mitigation in my environment, but users should not unexpectedly lose access to their development tool after an update and have to discover this workaround themselves.

Please validate the fix with VoiceOver enabled, including reading and navigating output during an active Codex session.

Additional information

Minimal confirmed workaround

Launch Codex with:

codex -c tui.animations=false

For a persistent user-level setting, add or update the existing [tui] section in ~/.codex/config.toml:

[tui]
animations = false

An explicit whimsy = false setting is not required. I tested removing that override while keeping animations = false, and VoiceOver continued to work correctly.

Investigation scope

The configuration comparison points toward animation-related terminal updates, but it does not identify the specific animation, rendering path, or code change responsible.

Please investigate animation-driven redraws and their interaction with macOS VoiceOver between the previously usable and affected versions. I am not asserting that Astra's sparkle effect is the cause.

This report concerns a regression with a confirmed workaround, rather than only a general request for a screen-reader-friendly interface.

[icambra]

Seeing this too, and I think I can point at the specific change.

Environment

• codex-cli 0.154.0 (Homebrew)
• macOS 26.4.1 (Darwin 25.4.0), arm64
• Apple Terminal 470, TERM=xterm-256color, COLORTERM=truecolor
• Model: gpt-6-astra
• VoiceOver

Same symptom as reported: VoiceOver continually re-announces fragments of output, to the
point of not being able to read the screen while a turn is in progress.

Likely cause

0.154.0 included #42842, "Add Astra sparkle effects to the TUI composer", which added
codex-rs/tui/src/bottom_pane/chat_composer/sparkle.rs. Per that PR, it renders
"sparse, fading stars across the composer" — an animated, continuously repainting
decoration drawn across the composer in the bottom pane.

That repaint loop looks like a good match for the reported behaviour: the decorative
cells are rewritten every frame, and VoiceOver treats the changed region as new content
to announce, on a timer, indefinitely.

Two preconditions from that PR would explain why this does not affect everyone:

1. It only renders when using an Astra model.
2. It only renders in a true-color terminal.

Both hold here, and the original report is also on GPT-6-Astra.

On the workaround

Worth noting there are two separate switches in the 0.154.0 config schema, and the
reported workaround uses the broader one:

• tui.whimsy — "Enable decorative effects such as Astra composer stars. Also requires animations." Default: true.
• tui.animations — "Enable animations (welcome screen, shimmer effects, spinners)." Default: true.

tui.animations = false also disables spinners, shimmer and the welcome screen. If the
sparkles are indeed the cause, tui.whimsy = false should be sufficient on its own and
would leave the other animations intact.

I do not think that has actually been isolated yet by either of us: because sparkles
require animations as well, testing whimsy = false while animations = false is
already set does not distinguish the two. Someone testing whimsy = false alone, with
animations left on, would confirm or rule out the sparkle hypothesis quickly.

Suggested resolution

Decorative, purely-aesthetic animation that repaints on a timer is a poor default for
screen-reader users, and tui.whimsy defaulting to true means affected users can lose
access to the tool on upgrade with no indication of why. Options that would help:

1. Do not repaint decorative cells when there is no other reason to redraw, so an idle
   composer produces no terminal churn.
2. Detect VoiceOver (defaults read com.apple.universalaccess voiceOverOnOffKey) or
   honour a documented accessibility setting, and default whimsy off in that case.
3. At minimum, mention tui.whimsy and tui.animations in the release notes of any
   release that adds an animated element.

This also overlaps with #20489 (screen-reader-friendly TUI mode), which is still open. A
general accessible mode would likely have caught this before it shipped.

[etraut-openai]

Yes, you can disable tui.whimsy or tui.animations to disable this feature if it conflicts with a screen reader.