tui: long answers from interactive (full-screen TUI) harness sessions render run-together / unreadable

[edwin-zvs]

Summary

A long answer from an interactive (full-screen-TUI) harness session (reproduced with an interactive codex session) renders run-together / with line breaks lost in the agentd pane, both in the live tail and when scrolled back — making it very hard to read once the answer exceeds the viewport.

Observed text (a numbered list the agent printed one-per-line) comes out concatenated:

… over the lazy dog1. CODEX line 2 — the quick brown fox jumps over the lazy dog2. CODEX line 3 — …

i.e. each list item runs straight into the next with no line break.

Important contrast

• Headless claude/codex sessions (plain streamed text) render the same list cleanly, one item per line, and scroll fine with C-x [ — verified.
• The breakage appears with interactive sessions where the harness runs its own full-screen TUI.

Repro

1. agent new codex "" --cwd <repo> (interactive PTY).
2. agent send <id> "Print a numbered list 1 to 60, one per line: 'CODEX line N — the quick brown fox jumps over the lazy dog'."
3. In the TUI, select it, C-x z to zoom; observe the answer is run-together; scrolling up keeps it run-together.

Status

Observed/reproduced via screenshots (vhs). Root-cause investigation in progress — checking whether the captured PTY bytes contain the newlines (renderer drops them) vs. the harness TUI emitting a reflowing paragraph / alt-screen, and whether pane↔harness width mismatch is involved. Will follow up with findings.

Related: #89 (per-client PTY width conflicts), #239 (resize history re-feed).

Found dogfooding scroll-up of long answers across harness sessions in the TUI.

[edwin-zvs]

Root cause (investigated)

TL;DR: Interactive harness sessions (codex, and any CLI that renders a cursor-addressed streaming TUI) emit a size-specific PTY byte stream. agentd renders interactive sessions by feeding that raw stream into a vt100::Parser and showing its grid + scrollback. When the viewing pane size differs from the size the child rendered at — which happens on attach / zoom / resize, and is made worse by a truncated-tail parser rebuild — the child's absolute cursor positions and scroll regions land in the wrong cells, producing the run-together blob. Headless sessions are immune because their prose arrives as structured Message events (plain text + newlines), not as a cursor-addressed stream.

Evidence

1. Headless vs interactive render path. The CLI folds Message/Reasoning events into history only for headless sessions (crates/cli/src/app.rs ~6740, guarded by if is_headless; comment: "PTY-backed sessions keep their prose in the PTY stream — skip to avoid double-render"). So interactive codex is rendered purely from its PTY byte stream, headless codex from clean structured messages. That's why the same 60-line answer is clean headless but garbled interactive.

2. codex is NOT an alt-screen app; it cursor-addresses the primary screen. Capturing codex 0.135's raw PTY at 150×42 (codex --sandbox read-only … "<prompt>"):

   • ESC[?1049h (alt-screen enter): 0
   • DECSTBM set-scroll-region ESC[t;br: 88 (e.g. (1,8), (9,42), (1,12))
   • reverse-index ESC M: 37
   • absolute cursor positioning ESC[r;cH: ~1600, erase-line ESC[2K: ~1270
     codex animates a pinned viewport on the primary screen using scroll regions + reverse-index.

3. A correct emulator renders codex's exact bytes cleanly. Feeding the captured stream into pyte (HistoryScreen 150×42) yields a clean grid (ROW 24…60) and clean scrollback (ROW 1…23, one per line). So the bytes are fine — the corruption is on agentd's side.

4. agentd renders the same session garbled (high-res screenshot attached): the whole zoomed pane is one wrapped blob, …lazy dog28. CODEX line 28 — …lazy dog29. CODEX line 29 — …, every item run together.

Why agentd specifically corrupts it

crates/cli/src/pty_render.rs replay_cached():

• On a cols change it rebuilds a fresh vt100::Parser and re-feeds only the tail of the raw byte history (reflow_tail_offset(...), ~lines 1072–1096). For a stream whose scroll-region/cursor-home setup lives at the start, a truncated tail (and/or a parser sized differently than codex assumed) makes every absolute ESC[r;cH / ESC[t;br land in the wrong cell → run-together.
• The code already guards against exactly this for alt-screen apps (~line 1056: "Alt-screen app (codex / vim / htop)… a truncated tail would render into the normal screen"), but the guard keys off screen().alternate_screen(). codex is not in alt-screen, so it falls through to the unsafe rebuild. The comment listing "codex" as an alt-screen example is stale for current codex.

Net: a full-screen/cursor-addressed TUI's historical byte stream can't be correctly re-rendered at a different size (the escapes are size-specific), and its scrollback can't be reconstructed by replaying a tail. Any attach/zoom/resize of such a session corrupts the display, and scrollback (which the child never repaints) stays corrupt.

Suggested directions

• Detect cursor-addressed / scroll-region streaming (DECSTBM / reverse-index / heavy absolute positioning), not just ESC[?1049h, and don't do the truncated-tail rebuild for those — repaint from the child instead (it already repaints live on SIGWINCH).
• For reading long answers from interactive harnesses, prefer the structured Chat view (Add structured TUI chat mode #309): it has the clean per-line Message events. Optionally fold those messages into scrollback for PTY sessions too (as headless already does), so "scroll up" shows readable prose instead of replayed TUI frames.
• Keep the child's PTY at the size it last rendered at (letterbox instead of resizing the parser) so historical cells stay aligned.

Method note

Reproduced on an isolated daemon (AGENTD_WEBUI_PORT=5760), codex-cli 0.135.0, pane 150×42, via direct pty.fork() capture + pyte, and vhs screenshots of the live TUI. Related: #320 (the scroll keys themselves don't work in a focused PTY).

[edwin-zvs]

Verbatim of the garbled interactive-codex render (zoomed, high-res — transcribed since GitHub CLI can't attach the PNG; artifact is local at /tmp/iso .../rd-bottom.png). The whole pane is one run-together blob — note items concatenated with no line break:

wm fox jumps over the lazy dog28. CODEX line 28 — the quick brown fox jumps over the lazy
dog29. CODEX line 29 — the quick brown fox jumps over the lazy dog30. CODEX line 30 — the
quick brown fox jumps over the lazy dog31. CODEX line 31 — the quick brown fox jumps over
the lazy dog32. CODEX line 32 — the quick brown fox jumps over the lazy dog33. CODEX line 33 …

For contrast, the same bytes through pyte at the same 150×42 render one item per line:

• ROW 1 done
  ROW 2 done
  …
  ROW 23 done      (ROW 24–60 in the live grid)

[edwin-zvs]

Correction — verified against the actual vt100 crate before implementing

I built a harness feeding the captured codex stream through the real vt100 0.16 crate (what agentd uses), at 150×42. Two surprises that overturn the truncated-tail hypothesis above:

1. The rebuild is not the garble trigger. Full feed, set_size-in-place, mid-stream resize, and a truncated-tail rebuild all render cleanly (0 run-together). So "don't do the truncated-tail rebuild" would not, by itself, fix the garble — the bare crate doesn't garble in any of those.

2. The crate keeps zero scrollback for codex (maxsb=0). codex steady-state sets DECSTBM scroll region (1,37) (37× in the capture) and scrolls the conversation inside it, pinning its input/status in rows 38–42. vt100 0.16 does not push lines scrolled off a partial region into the scrollback ring. (pyte does — which is why my earlier pyte test showed ROW 1–23; the crate agentd actually uses does not.) Confirmed not a teardown artifact: the stream has no ESC[3J / ESC[2J / RIS / alt-screen.

Implication: for codex there is no PTY scrollback to scroll — the earlier lines of a long answer never enter the terminal model agentd keeps. No resize/rebuild fix recovers them. The correct fix is to scroll the structured Message events (codex emits each line as a Message; agentd already records all 60), i.e. the Chat-view / fold-messages-into-scrollback path. Line-oriented harnesses (claude, shell) scroll the full screen and do populate scrollback normally.

The original run-together screenshots are a separate, not-yet-localized effect (likely the live-resize / codex-repaint interaction inside agentd's pty_render pipeline, which a bare-crate harness doesn't reproduce). But the scrollback-absence is the decisive blocker, and it points at the semantic-message fix rather than the pty_render rebuild.

[edwin-zvs]

Resolution — the run-together garble does not reproduce; agentd renders codex cleanly

I drove agentd's actual render path (ItemHistory::feed_pty → replay) with captured codex streams — short lines, long wrapping lines, and a mid-stream 150→64 resize (live SIGWINCH) — and dumped the grid line-by-line. In every case (live view, after resize, interleaved feed) the output is clean: one list item per wrapped line, max_items_per_line == 1, zero run-together. Example, long lines @64 cols:

49. CODEX line 49 - the quick brown fox jumps over the lazy
   dog

50. CODEX line 50 - the quick brown fox jumps over the lazy
   dog

The earlier "run-together" was a misread of low-resolution vhs screenshots: at a wide/zoomed pane each item sits on its own row, but adjacent monospace rows blur together at screenshot scale and read as one continuous paragraph. Both the vt100 crate and ItemHistory render codex correctly. My earlier root-cause comments (truncated-tail rebuild; maxsb=0) were chasing this phantom and are withdrawn — maxsb=0 is only the main parser; the shadow parser does provide scrollback (maxsb 57–335 across captures).

So this is not a rendering bug. The real friction reading a long answer is #320: in a focused/zoomed PTY, PageUp/PageDown are captured by the child and don't scroll, so you can't navigate past the viewport with the natural keys. The one thing worth a separate look is shadow-scrollback completeness (in a static feed I saw 19–60 of 60 lines recovered depending on width/timing), but that's distinct from the garble claimed here.

Recommend closing in favor of #320. Apologies for the noise — filed on a misread; verifying before writing the fix is what caught it.

[edwin-zvs]

Fix opened in #328 — renders PTY scroll-up from the structured message log (covers both the codex scroll-region case and the claude cursor-up-redraw case found here). The garble symptom this issue originally described was a screenshot misread; the real, reproducible problem is the scroll-up reconstruction, which #328 fixes.