[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)

Status Open
Reported on v2.1.119
Maintainer reply None cached
Activity 0 comments · opened Jul 25, 2026

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 = 0 and

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

  1. Open Claude Code in Ghostty on macOS.
  2. 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.

  1. 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.)

  1. Observe stale cells to the right of the newly rendered content, and the same

message rendered at two different widths.

  1. 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.

View original on GitHub ↗