`/status` output becomes unreadable once queue lines exceed the terminal width

Resolved 💬 2 comments Opened Nov 11, 2025 by Jarrodsz Closed Jan 10, 2026

Summary

/status in the GitHub Codex CLI becomes unreadable once the command queue contains entries that exceed the terminal width or when the scrollback buffer is already full of long output. Rows wrap mid-cell, columns overlap, and the queue table can no longer be interpreted.

Steps to Reproduce

  1. Launch the GitHub Codex CLI inside a standard 120x30 terminal window.
  2. Queue roughly 10 commands whose display text is wider than the terminal (long shell commands or chunked prompts work well).
  3. Produce additional output to fill the scrollback (e.g., run ls -R multiple times) so the prompt sits at the very bottom of the viewport.
  4. Run /status.

Expected Behavior

/status should render a stable, column-aligned table regardless of prior output volume or line length, wrapping or truncating gracefully so every queued command remains readable.

Actual Behavior

The table renderer does not reset the viewport or constrain line length:

  • Long command descriptions wrap mid-row, shifting columns under each other.
  • Subsequent rows inherit the wrapped layout so the queue, run log, and timings overlap.
  • In heavy-output sessions, /status leaves the terminal in a corrupted state where even re-running /status does not recover the table.

Impact

Operators cannot trust /status once they run batch jobs or have long queue entries—the exact scenario /status is meant to help with. I routinely need to clear the entire terminal or restart the CLI just to see the active queue, which kills situational awareness.

Environment

  • GitHub Codex CLI public build (observed 2025-02-15)
  • macOS Sonoma 14.4 (23E214), iTerm2 Build 3.5.0beta10
  • Reproduced with both light and dark themes; no shell customizations involved

Proposed Direction

Clearing the screen before rendering /status, truncating or ellipsizing command text per column width, and ensuring the layout uses the detected terminal width (without assuming a fixed 80 columns) should eliminate the overlap. A fallback to multi-line cards for extremely long entries would also work.

Acceptance Criteria

  • /status always renders with aligned columns regardless of queued text length.
  • Long command titles wrap or truncate without overwriting adjacent columns.
  • Re-rendering /status in a busy session never corrupts the rest of the prompt output.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗