[BUG] Resize leaves stale cells to the right of the new render — isolated to the TUI renderer via an htop control (macOS, Ghostty, v2.1.220)
Summary
After a terminal resize, Claude Code repaints its live region but does not clear
the cells outside its new width. Old wide-render text remains to the right of
the new narrower render, and the same message can appear twice at two different
widths. Ctrl+L clears it; content already committed to scrollback stays broken
permanently.
The new information in this report is a control experiment that isolates the
fault to Claude Code's renderer rather than the terminal, the window manager,
or window geometry. The earlier reports in this area (see Prior art) did not rule
those out, and the chain went quiet at 2.1.119. This still reproduces on 2.1.220.
Control experiment
Same terminal, same window, same resize operations, back to back:
| Program in the pane | Result after resize |
|---|---|
| htop | Redraws cleanly. No stale cells, no duplication. |
| claude | Stale cells remain right of the new width; content duplicated at two widths. |
Because htop is driven by the same SIGWINCH and the same pty on the same
emulator and repaints correctly, the terminal's resize/reflow path is working.
The difference is in what Claude Code emits after the size change.
Also ruled out
- Window geometry. Window frames were measured directly, not eyeballed. All
panes were identical to the pixel (726x450 in a 2x2 on a 1470x956 screen), with
uniform 6px gaps on every edge. The panes are not subtly mismatched.
- Terminal padding. Reproduces with Ghostty
window-padding-x/y = 0and
window-padding-balance = true, i.e. with no terminal-side padding at all.
- A missed SIGWINCH. Re-sending SIGWINCH to the process after the layout
settled changes nothing — which is expected, since the resize already delivered
a real pty size change. The signal is arriving; the repaint is incomplete.
- Window manager. Reproduces on a plain manual drag-resize with no tiling WM
involved (see step 3 below).
Steps to reproduce
- Open Claude Code in Ghostty on macOS.
- Run a prompt that produces a wide multi-line response — a tool-call block or a
diff works well, anything whose lines approach the full window width.
- Drag-resize the window narrow, then wide, then narrow again. (A tiling WM that
changes the window size will do the same thing; it is not required.)
- Observe stale cells to the right of the newly rendered content, and the same
message rendered at two different widths.
- In the same window, quit Claude Code, run
htop, and repeat step 3. It
redraws cleanly.
Expected
After a resize, the live region is fully cleared to the new width before
repainting, leaving no cells from the previous render.
Actual
Cells outside the new width retain their previous contents. Example fragment
captured from a real session, where old wide-render text sits to the right of the
new narrow render:
2>/dev/null | head…) ⎿ USAGE: subscribe [-h|--help] [--al
Environment
- Claude Code: 2.1.220 (latest at time of filing)
- macOS: 15.6.1 (Darwin 24.6.0, build 24G90), Apple Silicon
- Terminal: Ghostty 1.3.1
TERM:xterm-ghostty,TERM_PROGRAM:ghostty- Shell: zsh
- Window manager: AeroSpace 0.21.3-Beta (not required to reproduce)
Impact
Any resize-heavy workflow. Switching between a full-screen pane and a tiled grid
corrupts every visible session, and Ctrl+L only recovers the live region —
scrollback above it is permanently mis-wrapped, because those lines were emitted
with hard newlines at their original width.
Prior art / why this is not a duplicate
This lineage was auto-closed as duplicates of one another rather than resolved:
- #46462 → closed as duplicate of #49086
- #49086 → closed as fixed in 2.1.116
- #52797 → closed as duplicate
- #53038 ("still reproducing on 2.1.119 after #49086 fix") → auto-closed as a
duplicate of #52797, which was itself already closed
Related and still open: #58906 (macOS, already labelled duplicate, last activity
2026-06-10), #62740 (multi-line prompt after resize, Ctrl+L fixes it).
Filing fresh rather than commenting on a closed-and-locked thread, because this
adds (a) reproduction on 2.1.220, four months and ~100 releases past where the
chain stalled, and (b) the htop control plus measured geometry, which together
exclude the terminal, the padding, the signal delivery, and the window manager.
Happy to fold this into an existing issue if maintainers prefer.
Screen recording available on request.