Animated login banner makes setup difficult for screen-reader users

Resolved 💬 4 comments Opened Sep 19, 2025 by mikolysz Closed Nov 20, 2025
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.39.0

Which model were you using?

n/a

What platform is your computer?

Darwin 24.3.0 arm64 arm

What steps can reproduce the bug?

  1. Enable a screen reader. On mac OS, you can launch the build-in VoiceOver via Command+F5, or, if on a touchbar Mac, Command + power button pressed three times. On Linux, enable Orca with alt+super+s (may not work on some distributions), on Windows, nable Narrator with ctrl+win+enter.
  2. If on Mac OS, notice that you can navigate around the terminal with VO + arrow keys (the combination VO refers either to ctrl+option or capsLock, whichever your prefer). VO reads terminal output correctly. If you type in a command such as ls, VO reads the output of that command.
  3. Launch codex without auth credentials present. Notice that the screen reader is spammed with random ASCII characters. If you try to navigate around the terminal, the cursor constantly jumps around due to the banner's refresh rate.
  4. Launch another TUI tool (such as Aider, Claude Code, Gemini CLI etc). Notice that this problem does not occur in those due to the lack of a banner, and output can be read normally.

What is the expected behavior?

There are two ways to solve this:

  1. Remove the banner for everybody, as it serves no useful purpose beyond "eye candy."
  2. Add a separate screen asking the user whether they are using a screen reader and require accessibility features. This screen must appear first, before any other setup screen. If the user indicates they need a screen reader, remove the banner on all the subsequent screens. It is not acceptable to try to detect a screen reader through platform APIs, as the device the user is accessing Codex from may be different from the one where Codex is physically running (WSL VM, sandboxed container, in-browser VS Code server, headless server accessed via SSH etc).

In my opinion, option 2 should be preferred, as there are other parts of Codex which could be further optimized for screen reader users, so knowing whether one is enabled would be beneficial.

What do you see instead?

see ahove

Additional information

Tested with Voice Over and tdsr on Mac OS. Behavior of other screen readers (on Windows and Linux) is similar, so the bug is very likely to affect all such tools.

View original on GitHub ↗

4 Comments

Orinks · 11 months ago

Yes, this definitely made setup difficult for me.

trypsynth · 9 months ago

I can also confirm that this made the initial on boarding experience with Codex much more off putting than it should've been as a screen reader user. Once I got through I started flying and loving it, but it almost turned me off completely.

etraut-openai contributor · 9 months ago

This will be addressed in the next release of the CLI (0.62.0). We've added a new TUI.animation config option that allows all animations to be disabled.

mikolysz · 9 months ago

How is a screen reader user supposed to know that they need to toggle a config setting to make codex accessible? This should be a question shown during setup time.

Alternatively, make the first screen the "choose your theme" screen, with a "no animations (recommended for screen reader users) option."