Terminal resize causes status bar duplication and blank line flooding on macOS

[tzh7505-png]

Environment:
- OS: macOS (Intel, 10.15.7)
- Hermes: v0.12.0 (2026.4.30)
- Python: 3.11.15
- Terminal: macOS Terminal.app

Steps to reproduce:
1. Start hermes in Terminal.app
2. Resize the terminal window by any method — mouse drag, Command+=, or Command+Shift+=

Actual behavior:
- The status bar line duplicates itself
- Dozens of blank lines flood the terminal
- The input area shifts down repeatedly
- The UI becomes unusable until the session is restarted with /clear

Expected behavior:
- Terminal content reflows smoothly on resize
- No duplication or blank lines

Technical note:
Likely a prompt_toolkit SIGWINCH handler issue — the layout invalidation during resize may not be atomic, causing rendering races. Suggested fix: ensure app.invalidate() is called and layout cache is cleared atomically on SIGWINCH.

Severity:
Cosmetic but impacts every resize operation, which is high-frequency on macOS.

[alt-glitch]

Likely duplicate of #19216 — same SIGWINCH resize rendering issue (status bar duplication + blank line flooding). #19216 identifies the specific infinite fullReset loop mechanism in Ink TUI; this report describes the same symptoms from the prompt_toolkit CLI path on macOS.

[alt-glitch]

Likely duplicate of #19216

[iArsalanshah]

Same issue here on the default macOS Terminal.app.

Environment:

• Terminal: Apple Terminal.app (macOS 26.4.1)
• Hermes: v0.12.0 (2026.4.30) — regular CLI mode (not --tui)
• TERM: xterm-256color

Trigger:
Dragging to resize the terminal window (any direction — both wider and narrower). The previous chat content disappears entirely, replaced by a blank/empty screen. The prompt and status bar may still show, but all conversation history is gone.

Frequency: Every resize, 100% reproducible.

[konsisumer]

Thanks for the report. There's already an attempted fix for resize ghosting in cli.py (PR #4960, shipped before v0.12.0) — it erases the screen and resets prompt_toolkit's renderer on every SIGWINCH. The fact that you're still seeing the symptoms in v0.12.0 means either it's not firing on your setup, not sufficient for your case, or interacting badly with something else. A few quick diagnostics will narrow it down:

1. Does Ctrl+L (or /redraw) restore a clean UI after a problem resize? This invokes the same recovery path manually, so the answer tells us whether the fix logic itself works in your terminal or is fundamentally broken there.
2. What's your prompt_toolkit version? Run python -c "import prompt_toolkit; print(prompt_toolkit.__version__)" in the same env hermes runs from. The internal _on_resize hook the fix overrides is private API and behaves differently across versions.
3. What's $TERM when you launch hermes (e.g. xterm-256color, vt100, screen-256color)? echo $TERM in the shell where you start hermes.
4. Are you running hermes inside tmux/screen/zellij or directly in Terminal.app? echo $TMUX$STY will show; multiplexers consume SIGWINCH and re-emit it differently.
5. Do you ever see the screen go fully blank / chat history erased on resize, or only the duplication-and-flooding pattern? @iArsalanshah's follow-up describes the blank-screen symptom on the same v0.12.0 — confirming whether you see one, the other, or both helps separate two distinct render bugs.

[29206394]

This might also be related: #21972 fixes the "conversation re-streaming from the beginning" problem that happens on macOS when using Command+Enter to maximize/restore the terminal window.

Root cause: #20444 introduced _resize_clear_ghosts which replays the entire _OUTPUT_HISTORY buffer after every SIGWINCH. This causes all recent output lines (streaming tokens, spinner frames, callable entries) to be rapidly reprinted.

The fix removes the _replay_output_history() call from _recover_after_resize, leaving prompt_toolkit native _on_resize to handle the redraw cleanly. Ctrl+L still works to restore full history via _force_full_redraw.

Feel free to test the branch: 29206394:fix/resize-no-replay