Scrollback corrupted for responses taller than the viewport: scrolling up shows the startup/trust-prompt frame plus a large blank gap instead of conversation history

---

Body:

Summary

When an assistant response is tall enough to exceed the terminal viewport, the scrollback buffer ends up in an inconsistent state. Scrolling up does not reveal the earlier part of the response — instead the viewport shows the initial startup frame (the "Claude Code'll be able to read, edit, and execute files here / Yes, I trust this folder" prompt), followed by a large region of blank rows, with only the tail of the long response rendered at the bottom of the screen.

The middle of the response — the majority of the content — is not reachable by scrolling at all.

Steps to reproduce

1. Open Claude Code in a terminal.
2. Accept the folder-trust prompt at startup.
3. Ask something that produces a response noticeably taller than the viewport (a long structured report, a multi-section analysis, a large table).
4. Once rendering finishes, scroll up with the mouse wheel / trackpad.

Expected

Scrolling up walks back through the conversation history: the full long response, then prior turns.

Actual

Scrolling up lands on the startup/trust-prompt frame. Below it is a tall band of empty rows, then the last few lines of the long response pinned near the bottom. The bulk of the response is unreachable — it is neither on screen nor in scrollback.

Screenshot

The assistant's output text has been redacted (solid band at the bottom) because it contained internal business content, but the layout is unmodified and is the point of the report: startup frame at top, large blank gap, orphaned tail band at the bottom.

Environment

• Platform: macOS (Darwin 27.0.0, Apple Silicon)
• Shell: zsh
• Terminal viewport at time of capture: ~1431x958 px

Impact

Long responses become partially unreadable. The current workaround is to have the assistant write its output to a file so it can be read outside the TUI, which defeats the purpose of the inline response.

Notes

This looks like an alternate-screen-buffer / re-render synchronization issue rather than a terminal-emulator problem — the startup frame reappearing in scrollback suggests stale frame content is being retained and scrolled into view instead of the real history.