[BUG] Scrollback duplication on terminal resize — bisected to 2.1.101 (still present in 2.1.119)

Resolved 💬 3 comments Opened Apr 25, 2026 by eyalev Closed Apr 25, 2026

What's Wrong?

Claude Code's TUI renders into tmux's primary buffer (not the alternate screen).
As of 2.1.101, every TUI re-render emits a fresh frame into the buffer
without scrolling back over the prior render — so each terminal resize
(SIGWINCH) and each in-conversation state change (tool call, etc.) leaves the
previous frame stranded in scrollback. This stacks up rapidly and pollutes
the user's terminal history with duplicates of the welcome logo, prompt
chrome, and assistant message bodies.

It's especially severe in mobile / tmux-on-web setups where SIGWINCH fires
constantly (URL bar show/hide, soft keyboard open/close, orientation
changes, tab switches).

What Should Happen?

Each re-render should overwrite the prior frame in place (as 2.1.100 does),
not append a fresh frame below it. Resizing the terminal should not produce
any duplicate UI lines in scrollback.

Steps to Reproduce

Minimal repro — no API calls needed, just terminal resize triggers it:

tmux kill-session -t cctest 2>/dev/null
tmux new-session -d -s cctest -x 120 -y 40
tmux send-keys -t cctest 'claude --dangerously-skip-permissions' C-m
sleep 10                                                          # let CC start

# 6 resizes
for w in 80 100 140 90 130 120; do
  tmux resize-window -t cctest -x $w -y 40
  sleep 1
done
sleep 2

# Count copies of the version banner — should be 1, will be 7
tmux capture-pane -t cctest -p -S -2000 | grep -c 'Claude Code v'

Expected: 1. Actual on 2.1.101 → 2.1.119: 7 (one initial + 6 leaked
copies, exactly one per resize event).

A second harness that prompts CC for a 3-line response then resizes 6 times
shows the conversation content itself leaks +30 lines (5 copies per
resize). Long conversations get catastrophic.

Bisection result

Tested every Linux x64 native build available on downloads.claude.ai from
2.1.100 through 2.1.119, 3 runs each on the bounding versions:

| Version | CDN upload (UTC) | Leak count (6 resizes) |
|---------|----------------------|------------------------|
| 2.1.100 | 2026-04-10 04:55 | 0 (clean) |
| 2.1.101 | 2026-04-10 18:36 | 6 (regression lands) |
| 2.1.102 | 2026-04-11 20:24 | 6 |
| 2.1.103 | 2026-04-11 23:09 | 6 |
| 2.1.104 | 2026-04-12 02:20 | 6 |
| 2.1.105 | 2026-04-13 19:45 | 6 |
| 2.1.109 | 2026-04-15 03:37 | 6 |
| 2.1.110 | 2026-04-15 20:25 | 6 |
| 2.1.113 | 2026-04-17 18:54 | 6 (first native build) |
| 2.1.114 | 2026-04-17 23:11 | 6 |
| 2.1.116 | 2026-04-20 19:10 | 6 (see note below) |
| 2.1.117 | 2026-04-21 21:38 | 6 |
| 2.1.118 | 2026-04-22 23:27 | 6 |
| 2.1.119 | 2026-04-23 21:16 | 6 |

The flip is exact and reproducible at the 2.1.100 → 2.1.101 boundary
(released ~14 hours apart on 2026-04-10).

Note on the 2.1.116 changelog entry

The 2.1.116 changelog says:

Fixed scrollback duplication in inline mode where resizing the terminal or large output bursts would repeat earlier conversation history

The above harness shows 2.1.116 still leaks 6 copies on 6 resizes,
identical to 2.1.101 and to the current 2.1.119. Either that fix targeted a
narrower case (mid-stream burst dup?) or it was regressed in a later
release. The "resizing the terminal" wording in the changelog matches
exactly what this issue reproduces.

Visual evidence

tmux capture-pane after the 6-resize harness on 2.1.101 (clean would
have one frame, this has many — each at the width set by the corresponding
resize):

 ▐▛███▜▌   Claude Code v2.1.101
▝▜█████▛▘  Haiku 4.5 with medium effort · Claude Max
  ▘▘ ▝▝    ~/test/shared-cwd

────────────────────────────────────────────────────────────  (60-col, initial render)
❯
────────────────────────────────────────────────────────────
  ⏵⏵ bypass permissions on (shift+tab to cycle)

 ▐▛███▜▌   Claude Code v2.1.101
▝▜█████▛▘  Haiku 4.5 with medium effort · Claude Max
  ▘▘ ▝▝    ~/test/shared-cwd

────────────────────────────────────────────────────────────────────────────────  (80-col, leaked from first resize)
❯
────────────────────────────────────────────────────────────────────────────────
  [Haiku 4.5] shared-cwd
  ⏵⏵ bypass permissions on (shift+tab to cycle)
 ▐▛███▜▌   Claude Code v2.1.101
▝▜█████▛▘  Haiku 4.5 with medium effort · Claude Max
  ▘▘ ▝▝    ~/test/shared-cwd
... (continues, one full UI block per subsequent resize) ...

Same harness on 2.1.100 produces a single block followed by blank lines
— the prior render is properly overwritten in place.

Mitigation tradeoff users currently face

Opus 4.7 was added in 2.1.111 (2026-04-16), six days after the leak
landed in 2.1.101. There is no version that has both Opus 4.7 and clean
scrollback rendering — downgrading to 2.1.100 caps the user at Opus 4.6.

Environment

  • claude --version: 2.1.119 (Claude Code)
  • Last working version: 2.1.100
  • Platform: Anthropic API
  • OS: Linux (Ubuntu)
  • Terminal: tmux (also reproduces via xterm.js/tmux web clients; native

xterm + tmux on Linux reproduces identically)

  • Model used in repro: Haiku (model is irrelevant; the bug fires before

any prompt is sent)

Related upstream context

Issue #44864 (primary-buffer rendering) and #2479 (avoid clearing
scrollback) cover the broader "CC renders in primary buffer" architecture.
This issue is specifically about the regression that 2.1.101 introduced
on top of that architecture
— re-renders no longer overwrite in place.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗