openai / openai/codex

Status animation makes mouse selection and copying unreliable in GNOME Terminal/VTE

Open Beginner friendly
#38,017 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug CLI TUI
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

Plus

Which model were you using?

Not model-specific.

What platform is your computer?

Ubuntu 24.04.4 LTS, Linux 7.0.0-28-generic x86_64, GNOME Wayland session.

What terminal emulator and version are you using?

GNOME Terminal 3.52.0 using VTE 0.76.0.

What issue are you seeing?

While Codex's animated status indicator is active, mouse selection of static
transcript text usually fails in GNOME Terminal/VTE. The highlight disappears
or never becomes visible while dragging; after releasing the mouse,
Ctrl+Shift+C copies nothing. The selected rows are not changing or scrolling.

Disabling animations makes selection reliable:

[tui]
animations = false

An equivalent rapid-update test does not reproduce in Ghostty.

What steps can reproduce the bug?
  1. In GNOME Terminal, start Codex with animations enabled (the default).
  2. Ask Codex to run sleep 300 and wait for it to complete.
  3. While the status indicator is animating, drag across static text earlier in
    the transcript.
  4. Release the mouse, press Ctrl+Shift+C, and try to paste.
  5. Repeat after setting tui.animations = false and restarting Codex.
What is the expected behavior?

Static transcript text should remain selectable and copyable while the status
animation is running.

Please reduce the status animation refresh rate from 32 ms (~31 Hz) to 100 ms
(10 Hz), or otherwise avoid emitting animation redraws more often than 10 Hz.

Additional information

The status widget schedules animation frames every 32 ms:

PR #2316 changed this interval
directly from 100 ms to 32 ms in August 2025.

A 100 ms interval also has precedent in popular terminal progress libraries:
Rich defaults to 10 refreshes per second,
tqdm defaults to a 0.1-second minimum interval,
and indicatif's official spinner example uses 100 ms.

In a minimal erase-and-rewrite test, selection almost always failed at 32 ms,
remained somewhat unreliable at 60 ms, and was reliable at 100 ms.

The existing VTE report for this behavior is:

A smaller reproducer and the interval measurements above are in:

Related report about the status animation's terminal traffic:

Avoiding redraws when the rendered shimmer has not changed would reduce the
terminal traffic further.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in codex-rs/tui/src/status_indicator_widget.rs, where the status widget schedules animation frames every 32 ms. Compare the existing interval with the reported 100 ms target, then reproduce the selection and copying steps in GNOME Terminal with animations enabled. Done means static transcript text remains selectable and copyable while the animation runs.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli, performance
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.