[BUG] Terminal resize causes repeated banner/content duplication in scrollback (per-frame redraw leak)

<img width="1456" height="1061" alt="Image" src="https://github.com/user-attachments/assets/38f63f05-cd05-4f4e-a095-f5f99d0026c6" />

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/46834
2. https://github.com/anthropics/claude-code/issues/47235
3. https://github.com/anthropics/claude-code/issues/49057

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The last stable version before this began occurring is 2.1.97. Previously, Claude would clear the entire scrollback any time it needed to redraw more than the current screen.

I know some users found this problematic when it would clear other content in the scrollback, but some of us found it useful particularly if we wanted to Ctrl-F through the scrollback and not see the same lines repeated over and over again (and for those of us who have our terminals configured for unlimited scrollback, this also just fills up more and more memory). A configurable option would be nice.

Seeing the same symptom on iTerm2 + tmux (latest) on macOS, running Opus 4.7 Max. Scroll past the banner and the entire conversation reprints 4-5 times, stacked in scrollback. Visible pane renders fine.

Haven't isolated resize as the trigger on my end, just notice the pile when I scroll up. Reproduces across multiple Claude Code versions over several months, so whatever's causing it predates recent releases.

Can drop an asciinema or tmux capture-pane if it helps confirm same root cause.

This issue was fixed as of version 2.1.116.

This issue does not appear to be fixed on 2.1.116. Resizing the terminal causes the total number of output lines in the scrollback indefinitely rise.

Me too, I'm in Mac terminal on 2.1.116 and I am still getting the issue. I can't even read PRDs in plan mode because they're split across tens of thousands of lines of text every time I generate one.

<img width="1470" height="956" alt="Image" src="https://github.com/user-attachments/assets/1223a4e8-0bee-4019-b6ea-1a6f77a24b68" />

<img width="1470" height="956" alt="Image" src="https://github.com/user-attachments/assets/9678877f-ef5c-41a4-a660-168cff2870e3" />

Agreed, not fixed as of latest version. A workaround for the time being is to stop and resume the session if you accidentally trigger it.

This issue still persists in version v2.1.118.

still persist in 2.1.119

still persists on windows 11 in v2.1.119

Confirming this still reproduces on v2.1.119 in VS Code integrated terminal (editor-pane terminal mode).

Environment

• Claude Code: v2.1.119
• OS: macOS (Darwin 25.3.0)
• Terminal: VS Code integrated terminal (Code.app), zsh

Trigger pattern observed

• Long assistant responses that contain multiple markdown tables (e.g. P0/P1/P2/P3 priority tables, follow-up tables for ops/compliance) during streaming.
• Resizing the VS Code editor pane (horizontally or vertically) while a response is streaming or shortly after it completes makes the duplication noticeably worse — every intermediate width/height pushes another frame into scrollback.
• Net result: the same table content appears twice — once as line-by-line plain text from streaming, then again as the box-drawn rendered table at the bottom — with the status banner ("Brewed for ... shells still running") wedged between the two.

Impact
Conversation history becomes unreadable after a few resizes; long technical reviews (which are exactly when this triggers) are the worst case.

This appears to be the same root cause described in the original report (SIGWINCH redraw not clearing the previous frame). The completed/closed status seems premature given that v2.1.118 / v2.1.119 reporters above still see it. Could this be reopened or linked to a tracking issue for the actual fix?

Tested across three terminal emulators on macOS (Apple Silicon M1)

Reproduced consistently on Claude Code v2.1.118 across:

iTerm2 — duplicates appear but are partially merged due to slower rendering. Typically 3 repeats on resize, more when split panes are involved.

Ghostty 1.3.1 — worst case. GPU rendering is fast enough to capture every intermediate frame during drag resize. Horizontal resize produces stacked copies at progressively different widths; vertical resize produces non-overlapping repeated frames. Far more duplicates than iTerm2.

macOS Terminal.app — partial frames visible (bottom portion only, no banner), suggesting render speed sits between iTerm2 and Ghostty.

Trigger conditions identified:

• Any window resize (drag) → repeats proportional to how many intermediate SIGWINCH signals are fired
• Opening a new split pane → all existing panes redraw multiple times simultaneously
• The more panes open, the more duplicates per resize event
• New window / claude resume <hash> with no subsequent resize → clean, no duplicates

Additional observation: trap '' WINCH in zsh does not help — Claude Code's Node.js process listens to SIGWINCH directly, bypassing shell-level signal trapping.

~~Temporary workaround: Ctrl+L forces a clean redraw after the fact.~~
Invalid, after several Ctrl+L other content are gone, but banner remains.

<img width="1690" height="1106" alt="Image" src="https://github.com/user-attachments/assets/54a06a03-a877-41ce-a439-fcc8d423b5f1" />

+1, on macOS

Still reproduces on Claude Code 2.1.141 / macOS 26.4 (Tahoe, Apple Silicon) /
Ghostty 1.3.1 stable (CoreText + Metal).

Triggering condition is much sharper in my setup: mixed CJK + Unicode
box-drawing tables make this dramatically worse. A single horizontal drag
of the window edge across a scrollback that contains a long CJK paragraph
plus a │ ─ ┌ ┐ table produces 20–40 stacked frame copies at progressively
different widths, with the box-drawing bars misaligned across reflow lines
and CJK paragraphs split mid-character. Pure-ASCII scrollback shows the
same pattern but with noticeably fewer duplicate frames per drag.

Confirmed NOT related to the terminal emulator. I spent an evening ruling
out Ghostty as the cause by toggling these one at a time:

• grapheme-width-method = legacy vs default unicode
• explicit CJK fallback (font-family = "PingFang SC" after primary)
• background-opacity = 1 + commenting out background-blur-radius (kills

the Metal transparency path entirely)

• swapping the primary font (JetBrains Mono Nerd Font Mono ↔ Maple Mono NF CN)

None of these change the symptom. The bug clearly lives in Claude Code's
SIGWINCH handler writing each in-flight resize frame into the normal
scrollback buffer, exactly as OP analyzed — alternate screen buffer would
isolate this.

CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 confirmed not to help here either.

Workaround I'm using meanwhile:

1. cmd+k (Ghostty clear_screen) after any accidental resize
2. Never resize the window while claude is streaming — Ctrl+C / Esc

first, resize, then resume

Would love to see this prioritized — for CJK users this is severe enough
that it interrupts review of any task that produced a Markdown table.

This needs to be re-opened as it still occurs and greatly impacts standard workflow.

Adding empirical evidence from a discriminating test pipeline run today (May 23, 2026)
that isolates the root cause to the Claude Code TUI itself, ruling out Windows Terminal,
ConPTY, and OS-layer hypotheses.

## Setup - Windows 11 Pro 24H2 build 26200.8457

• Claude Code v2.1.150 (Opus 4.7 1M context)
• Output captured to file for each test

## 4 discriminating tests

| # | Terminal host | Process producing output | Resize during render | A59 reproduced? |
|---|---|---|---|---|
| 1 | Antigravity (VS Code fork) integrated terminal | Claude Code Linux (WSL2 Ubuntu-24.04) | Yes | ✅ Yes |
| 2 | Windows Terminal v1.24.11321.0 (current Preview) | Claude Code Linux (WSL2) | Yes | ✅ Yes |
| 3 | Windows Terminal v1.21.10351.0 (downgraded, pre-ConPTY passthrough refactor v1.22+) | Claude Code Linux (WSL2) | Yes | ✅ Yes — actually worse (6× and 9× duplications of
section headers in scrollback) | | 4 | Windows Terminal v1.21.10351.0 | PowerShell 7.6.2 (Get-Content ... \| Out-Host, no Claude Code) | Yes | ❌ No duplication (488 lines output, 0 duplicates) |
## Conclusions by Popper-style elimination

• Test 3 eliminates Windows Terminal v1.22+ passthrough refactor as a candidate — bug reproduces even on v1.21 pre-refactor.
• Test 4 eliminates ConPTY-underlying race conditions — same Windows Terminal, same resize during render, but without Claude Code = no duplication.
• Tests 1+2+3 vs Test 4 surgically isolate Claude Code TUI as the only common factor between setups that reproduce A59 and the clean setup.

## Cross-platform corroboration Issue #57145 reports the same duplication on macOS, which has neither ConPTY nor Windows Terminal. This is decisive empirical evidence that the root cause is platform-independent and lives in the Claude Code TUI renderer itself.

## Suggested root cause (from community discussion in this thread)

> The TUI renderer does not properly clear previous frames on SIGWINCH (UNIX) / WM_SIZE
> (Windows) before redrawing, pushing duplicate content into the scrollback buffer.

## Workaround currently used

We apply a local "Mode Calame" discipline (avoid resize during long output, prefer multiple
short responses) until upstream fix lands. The /tui no-op redraw mentioned in #52731 is
not exposed in standard Claude Code releases.

Happy to share the captured output files demonstrating the 4 test outcomes if useful
for the engineering team.

Related issues with same symptom or contributing context: #57145 (cross-platform macOS),
#46981, #49057, #54732, #57133, #58906, #52731 (/tui no-op redraw workaround), #51393
(parent regression Opus 4.7).

still happening in macos

same here still happening in macos

there problem is not fixed and still reproducing when using tmux on following platforms: ubuntu 24.04, fedora 44 kde, wsl2 (windows 10)

this workaround /tui no-op redraw doesn't exist:

/tui no-op redraw
  ⎿  Unknown renderer "no-op redraw". Usage: /tui <default|fullscreen>

update: the correct workaround, i suppose, is: /tui fullscreen - but it seizes tmux mouse events in current pane

This is not exactly the same issue, but it stems from the same root cause which is that Claude Code no longer clears and redraws the whole scrollback when it redraws a UI element that extends into the scrollback: https://github.com/anthropics/claude-code/issues/65713