Status details can overflow the terminal after an ellipsis is added

What version of Codex CLI is running?

codex-cli 0.0.0, built from the audited source revision d43f1e7eb27b204fd0e565891869280df3ba2346. Running codex --version on that isolated source build returned codex-cli 0.0.0. No host-installed Codex binary was used.

What subscription do you have?

Not applicable to this local reproduction. No Codex account was logged in or used.

Which model were you using?

Not applicable. No model request was made.

What platform is your computer?

Linux x86_64. This is the sanitized result of uname -mprs; host-specific kernel fields are omitted from the public draft.

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

The reproducer runs as a non-interactive Bash/Cargo process, with no terminal emulator and no multiplexer. It builds the pinned source into a separate temporary target directory and uses a separate CODEX_HOME.

Codex doctor report

What issue are you seeing?

The status details widget can produce a line wider than the terminal after it
adds its ellipsis. Details are first wrapped by terminal-cell width, but the
last retained line is then shortened with chars().take(max_base_len) before
the ellipsis is appended. With wide characters, that scalar limit keeps too
many cells.

At a 10-column viewport, a four-cell status prefix leaves six content cells.
For details made of repeated 界, the final row is rendered as
界界界…, which is 11 cells wide. The ellipsis is consequently clipped
or the row overwrites the right edge.

What steps can reproduce the bug?

From this report directory, run:

bash attachments/repro.sh

On its first run, the wrapper builds codex-cli from the pinned source
revision into isolated CARGO_HOME and CARGO_TARGET_DIR directories. It
prints the matching codex --version, then runs the source-level status
oracle. The wrapper intentionally exits with status 1 when the current source
violates the invariant.

The equivalent local UI state is a status update whose details are 20 copies
of 界, in a 10-column terminal with the status detail row cap set to three
lines. The source-level target check produces:

target=["    界界界", "    界界界", "    界界界…"] widths=[10, 10, 11]
expected=["    界界界", "    界界界", "    界界…"] widths=[10, 10, 9]
FAIL status details overflow after ellipsis ...
checked=1 failures=1

The oracle is local and deterministic: it does not make a model request, log
in, or contact a provider. It mirrors the target helper and checks the
viewport invariant at the pinned revision, while the wrapper separately
verifies the matching Codex CLI build. The repeated-run output and checksum
are in attachments/evidence.log; runtime details
are in attachments/environment.txt.

What is the expected behavior?

Every returned status row should fit within the viewport, including the prefix
and ellipsis. The final row should be truncated by display-cell width at a
grapheme boundary before the ellipsis is added.

Additional information

The audited source revision is
d43f1e7eb27b204fd0e565891869280df3ba2346. Public Codex main was checked
at c4017a87aacc7558002b7cb510025e967c1d765e on 2026-09-12, and the
relevant status and truncation files were unchanged. The report is pinned to
the audited revision.

wrapped_details_lines establishes the prefix width with
UnicodeWidthStr and passes the viewport width to word_wrap_lines:

status_indicator_widget.rs

When the line cap is exceeded, the final span is rebuilt by taking a scalar
count and then appending a one-cell ellipsis:

status_indicator_widget.rs

The final output is then returned directly from lines and rendered as part
of the status row:

status_indicator_widget.rs

For width 10, the four-cell prefix leaves six cells. max_base_len becomes
five, so chars().take(5) keeps five CJK scalars, which already occupy ten
content cells before the ellipsis. The line-width invariant is broken by the
second truncation step even though the initial wrapping is cell-aware.

I searched the existing public Codex issues and did not find an issue for this
status-details ellipsis case. The attached oracle checks the viewport
invariant directly and the ASCII control path remains valid.

The report artifacts are:

• repro.sh
• evidence.log
• environment.txt
• codex-doctor.json
• attachments.zip

attachments.zip

Start in codex-rs/tui/src/status_indicator_widget.rs, especially wrapped_details_lines and the final-row truncation around lines 178-207. Run attachments/repro.sh to reproduce the width failure, then verify that wide-character status details remain within the viewport after the ellipsis while the ASCII control path still passes.