[BUG] Streaming output trimmed live by prompt repaint — long responses never reach terminal scrollback

Bug Description

While an assistant response streams in the Claude Code TUI, output is trimmed live as it renders: the pinned input prompt / header repaints in place, and every line that scrolls past the top of the repaint region is overwritten instead of being committed to the terminal's native scrollback buffer.

The consequence is that once a response (or thread) grows taller than the viewport, it becomes impossible to scroll up and read it — the earlier content is simply gone from the terminal. This is not an occasional glitch: it affects every long session, which in my usage is essentially all of them. I routinely watch an answer stream by and then cannot go back and read what it said.

Most recently observed in the background-jobs / agent view (the screen with the "describe a task for a new session" input): a session's output rendered below the input line was visibly trimmed as it streamed, with the region above the viewport blank rather than scrollable.

I first reported this via the in-app /bug command several weeks ago; filing here so it is publicly trackable.

Steps to Reproduce

1. Open Claude Code in a plain terminal (TERM=xterm-256color) on macOS.
2. Ask anything that produces a response longer than the terminal height (or open the agent view on a running background session with long output).
3. While/after it streams, try to scroll up with the terminal's native scrollback.

Expected

Rendered output is committed to the terminal scrollback as it scrolls out of the viewport, so a long response/thread remains fully readable by scrolling up — like any ordinary CLI program.

Actual

Content above the viewport is trimmed/overwritten by the repaint. Scrolling up shows blank space or a corrupted partial frame; the beginning of the response is unrecoverable in the terminal.

Environment Info

• Platform: darwin (macOS, Darwin 25.4.0)
• Terminal: xterm-256color
• Version: 2.1.207

Related issues

This looks like the same underlying renderer behavior as:

• #75967 — long assistant messages truncated in transcript scrollback (identical symptom, background session)
• #72529 — TUI scrollback buffer insufficient for long responses
• #69577 — repaint rewinds past viewport top with no alternate screen, frames leak into scrollback
• #68755 — inline renderer corrupts terminal scrollback with interleaved overwrites
• #75597 — feature request to anchor viewport at top of each response (a workaround for this same pain)
• #42002 / #42738 / #28077 — earlier reports of scrollback loss in long sessions
• #41965 (dup of #41814) — identified the v2.1.89 flicker-free rendering change as the point where scrollback preservation regressed, with CLAUDE_CODE_NO_FLICKER=0 as the opt-out

The distinguishing detail in this report: the loss happens during streaming — the content never reaches the scrollback buffer in the first place, so no amount of scrolling after the fact can recover it. Opt-out env vars and /export are damage control; the default renderer of an interactive CLI should not destroy the user's ability to read what it just printed. Given how many separate issues describe this same loss, please consider treating the renderer/scrollback behavior as one prioritized defect rather than isolated reports.