[BUG]TUI banner duplication stacking repeatedly on macOS Terminal.app (v2.1.104) — blocking daily work

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/46462
2. https://github.com/anthropics/claude-code/issues/46834
3. https://github.com/anthropics/claude-code/issues/46499

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

Update: Switching to iTerm2 did NOT fix the issue.

I followed community suggestions and installed iTerm2 (3.6.9, official build from Homebrew), but the TUI banner duplication is still happening — the
entire Claude Code interface (logo, version, working directory, input box, status bar) continues to stack repeatedly in the same window after any
interaction, with each copy rendered at a different width.

Additional workarounds I've tried (all failed):

• ✗ Setting CLAUDE_CODE_NO_FLICKER=1
• ✗ Cleared all SessionStart hooks
• ✗ Switched from Terminal.app to iTerm2
• ✗ Confirmed no hook writes to stdout during startup
• ✗ Did not resize the window manually

This is not a terminal-emulator issue — it reproduces across both Terminal.app and iTerm2, which strongly suggests the root cause is in Claude Code's TUI
rendering layer (likely ink/React not using the alternate screen buffer, or repeated SIGWINCH-driven full redraws without clearing the previous frame).

<img width="962" height="1088" alt="Image" src="https://github.com/user-attachments/assets/79d84301-7337-4310-87b3-5b11bb79ac54" />

Hitting this on macOS Terminal.app, Claude Code 2.1.104, Darwin 25.4.0, zsh. Custom
▎ statusLine configured in ~/.claude/settings.json (single-line output with ANSI colors
▎ and multibyte ·/⚡ characters). Scrollback accumulates duplicate copies of the
▎ statusline + model banner throughout a session — after ~1hr of use, scrolling up shows
▎ the CID line repeated dozens of times interleaved with actual output. Screenshots
▎ attached.

<img width="676" height="512" alt="Image" src="https://github.com/user-attachments/assets/654e2f84-c944-4222-a927-51060a1db05e" />

Undergoing the same issue. I think it arrived with 2.1.68 or something around the time of the 1M context, at the time if i remember i had it isolated to only iterm2 and even with zellij adn messing with the settings, i had problems with using Better Snap Tool and windows resizing. Suddenlty it is now occurring in terminal as of the most recent update

▗ ▗ ▖ ▖ Claude Code v2.1.104
Opus 4.6 (1M context) · Claude Max
▘▘ ▝▝ ~/CCP/P05-Testing-Ground-02-28-26

❯ having terrible probelms with bettersnap tool and using the commands in bettersnap tool to rezie terminal windows right now, move
terminal windows, resize the terminal windows, moving terminal windows with my better snap tool commands. this hasn't happened for a
long tiem. it occurred at one point around a change to like claude code 2.1.68 or something and we resolved it but it ruined
iterm2. so far i've stayed in terminal .. it was working fine earlier but suddenly now there seems to be whenever i open betternsap
tool and try to resize claude code in terminal it elongates / repeats certaion responses and adds so many additional lines.

✢ Gesticulating… (11s · thinking)

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯ 
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
0─────────25────────50────────75──87───100 [0/1,000,000|0%] P05-Testing-
┃──────────│─────────│─────────│───│─────┃ In:0|Out:0|Total:0 Ground-02-28-26 0 tokens

▗ ▗ ▖ ▖ Claude Code v2.1.104
Opus 4.6 (1M context) · Claude Max
▘▘ ▝▝ ~/CCP/P05-Testing-Ground-02-28-26

❯ having terrible probelms with bettersnap tool and using the commands in bettersnap tool to rezie terminal windows right now, move terminal
windows, resize the terminal windows, moving terminal windows with my better snap tool commands. this hasn't happened for a long tiem. it
occurred at one point around a change to like claude code 2.1.68 or something and we resolved it but it ruined iterm2. so far i've stayed in
terminal .. it was working fine earlier but suddenly now there seems to be whenever i open betternsap tool and try to resize claude code in
terminal it elongates / repeats certaion responses and adds so many additional lines.

✢ Gesticulating… (11s · thinking)

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯ 
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
0─────────25────────50────────75──87───100 [0/1,000,000|0%] P05-Testing-
┃──────────│─────────│─────────│───│─────┃ In:0|Out:0|Total:0 Ground-02-28-26 0 tokens

▗ ▗ ▖ ▖ Claude Code v2.1.104
Opus 4.6 (1M context) · Claude Max
▘▘ ▝▝ ~/CCP/P05-Testing-Ground-02-28-26

❯ having terrible probelms with bettersnap tool and using the commands in bettersnap tool to rezie terminal windows right now, move terminal windows,
resize the terminal windows, moving terminal windows with my better snap tool commands. this hasn't happened for a long tiem. it occurred at one
point around a change to like claude code 2.1.68 or something and we resolved it but it ruined iterm2. so far i've stayed in terminal .. it was
working fine earlier but suddenly now there seems to be whenever i open betternsap tool and try to resize claude code in terminal it elongates /
repeats certaion responses and adds so many additional lines.

✢ Gesticulating… (11s · thinking)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯ 
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
0─────────25────────50────────75──87───100 [0/1,000,000|0%] P05-Testing-
┃──────────│─────────│─────────│───│─────┃ In:0|Out:0|Total:0 Ground-02-28-26 0 tokens

▗ ▗ ▖ ▖ Claude Code v2.1.104
Opus 4.6 (1M context) · Claude Max
▘▘ ▝▝ ~/CCP/P05-Testing-Ground-02-28-26

❯ having terrible probelms with bettersnap tool and using the commands in bettersnap tool to rezie terminal windows right now, move terminal windows,
resize the terminal windows, moving terminal windows with my better snap tool commands. this hasn't happened for a long tiem. it occurred at one point
around a change to like claude code 2.1.68 or something and we resolved it but it ruined iterm2. so far i've stayed in terminal .. it was working fine
earlier but suddenly now there seems to be whenever i open betternsap tool and try to resize claude code in terminal it elongates / repeats certaion
responses and adds so many additional lines.

✳ Gesticulating… (11s · thinking)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯ 
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
0─────────25────────50────────75──87───100 [0/1,000,000|0%] P05-Testing-
┃──────────│─────────│─────────│───│─────┃ In:0|Out:0|Total:0 Ground-02-28-26 0 tokens

Seeing the same issue for a few days now.

Confirming this reproduces on Windows 11 / Git Bash (MSYS2) — not just macOS Terminal.app. The symptom is slightly different but the signature matches: SIGWINCH/redraw-triggered scrollback duplication.

Environment:

• Windows 11 Home 10.0.26200
• Shell: Git Bash (MSYS2 bash)
• Claude Code v2.1.114
• Opus 4.7 (1M context), medium effort
• 6 SessionStart hooks configured (2 global + 4 project-level)

Symptom on Windows:
Instead of only the startup banner stacking, the last full assistant message gets re-emitted 2–6× into scrollback during long-running tool calls (4 parallel sub-agents, ~7.5 min total). Each copy is intact — not progressively narrower like the macOS report. Banner (\▐▛███▜▌ Claude Code v2.1.114\) also re-prints between duplicates, and the most recent user prompt appears to echo again.

Trigger pattern:

• Most reliable during parallel \Task\/\Agent\ tool calls with background sub-agents
• Also fires when PostToolUse hooks print to stdout during long waits
• Statusline script (Node, ~260 LOC, tickers) appears to amplify — each tick seems to push another copy into scrollback rather than updating in place

Workarounds tried:

• \CLAUDE_CODE_NO_FLICKER=1\ just set, will report back after a few days
• Disabling individual hooks did not prevent duplication

Related: Closed issue #21039 (\"Multiple startup banner renders on Windows — Ink initializes 3 times\") looks like the same root cause regressing. Worth reopening or linking.

Still reproducing on v2.1.116 on macOS Terminal.app — despite the sibling issue #47235 being marked as "fixed as of version 2.1.116". Posting an updated repro + bisection here because the trigger appears to be subtly different from pure SIGWINCH.

Environment

• Claude Code v2.1.116
• Model: Opus 4.7 (1M context), xhigh effort · Claude Max
• macOS (Darwin 25.4.0)
• Terminal: Apple Terminal.app v470, Basic profile, default size 80×24
• Shell: zsh
• TERM=xterm-256color, COLORTERM=truecolor, TERM_PROGRAM=Apple_Terminal
• No tmux / screen, no multiplexer
• Window is not manually resized at any point

Symptom

On fresh launch of claude --dangerously-skip-permissions in a default-sized Terminal.app window, the welcome banner + border + status line is rendered 6–10 times in succession, each frame with a progressively wider horizontal separator:

frame 1 separator: ~120 cols
frame 2 separator: ~127 cols  (+7)
frame 3 separator: ~133 cols  (+6)
frame 4 separator: ~140 cols  (+7)
frame 5 separator: ~148 cols  (+8)
frame 6 separator: ~157 cols  (+9)
frame 7 separator: ~165 cols  (+8)
frame 8 separator: ~173 cols  (+8)

Growth stops once the frame width reaches the actual terminal width. The live alt-screen pane (prompt area) works correctly afterwards, but scrollback is flooded with stacked welcome frames.

Abbreviated paste:

▗ ▗   ▖ ▖  Claude Code v2.1.116
           Opus 4.7 (1M context) with xhigh effort · Claude Max
  ▘▘ ▝▝    ~/.../VPN

────────────────────────────────────────────────────────   (~120 cols)
❯
────────────────────────────────────────────────────────   (~120 cols)
  [Opus 4.7 (1M context)] | ━━━━━━ 0% (0/1000K) | VPN | git:(master) | 1 MCPs | ⏱ 0m
  ⏵⏵ bypass permissions on (shift+tab to cycle)

▗ ▗   ▖ ▖  Claude Code v2.1.116
           Opus 4.7 (1M context) with xhigh effort · Claude Max
  ▘▘ ▝▝    ~/.../VPN

───────────────────────────────────────────────────────────   (~127 cols)
❯
...

Bisection

| Condition | Cascade? |
|---|---|
| claude --dangerously-skip-permissions in 80-col window | Yes |
| Plain claude (no flag) in 80-col window | No |
| claude --dangerously-skip-permissions in window pre-sized to ≥155 cols | No |

The only user-visible difference between the flagged and unflagged code paths is the extra footer line ⏵⏵ bypass permissions on (shift+tab to cycle), which is rendered only when --dangerously-skip-permissions is active.

Hypothesis

The footer contains ⏵ (U+23F5, BLACK MEDIUM RIGHT-POINTING TRIANGLE), which has ambiguous East Asian Width. macOS Terminal falls back to Apple Color Emoji and renders it as a 2-column emoji glyph, while string-width / wcwidth-style measurement in the TUI (no VS16 U+FE0F present) counts it as 1 column. Two such glyphs (⏵⏵) plus a space = a 4-column rendering miscounted as 2 columns.

A similar ambiguity exists for ⏱ (U+23F1) in the statusline when a user has a custom statusline script containing it. In the flagged code path the miscount is on a line rendered by CC itself, not by user config — so any user running --dangerously-skip-permissions in a narrow window will hit it, not just those with custom statuslines.

The growth pattern is consistent with: content overflows the TUI's assumed width → layout engine retries with a larger width → overflows again (because the underlying measurement is still wrong) → retries wider → eventually catches up to the terminal's actual width, at which point the mismatch becomes moot.

The fact that pre-sizing the window to ≥155 cols eliminates the cascade supports this: when actual width already exceeds the overflow point from the first render, the retry loop never fires.

Related: this is the same general Unicode-width-miscalc family as #30471 ("TUI misalignment caused by string-width miscalculating emoji character width on macOS 12") and #46909 ("Permission mode icon U+23FA ⏺ renders as two garbled boxes"). The U+23Fx block (media control symbols) is particularly affected — these are ambiguous-width glyphs that terminals render via emoji fallback but string-width tables often classify as 1-col.

Regression window

Started appearing for me ~2 days prior to 2026-04-21. Earlier versions on the same hardware / same Terminal.app / same settings did not cascade.

Workarounds

• Set Terminal profile default size to ≥155 cols (Settings → Profiles → Basic → Window → Columns/Rows); this eliminates the cascade because the first render already has enough width
• Launch without --dangerously-skip-permissions (removes the triggering ⏵⏵ footer line)

Neither is a fix — the bug is in CC's width measurement / overflow-retry behavior.

Suggested fixes

1. Replace ⏵ (U+23F5) with a width-stable glyph in the bypass indicator — e.g. plain >> (two ASCII chars) or include U+FE0F (VS16) after each ⏵ to force emoji presentation and align the width assumption across terminal and TUI.
2. On layout overflow during startup rendering, do not retry with a wider width assumption — the terminal's reported dimensions are authoritative. Clip or wrap instead.
3. Audit all CC-emitted lines for U+23Fx and other ambiguous-width codepoints (stopwatch ⏱ U+23F1, record ⏺ U+23FA, etc.) and normalize via VS16 or ASCII substitution.

Happy to provide additional logs or a terminal recording (asciinema) if useful.

Same here

Not a duplicate. Distinct trigger, signature, and root cause from #46462 / #46834 / #46499 / #47235.

| | #47235 (closed, "fixed in 2.1.116") | #46983 (this) |
|---|---|---|
| Trigger | Terminal resize | Fresh launch of claude --dangerously-skip-permissions in <155-col window. No resize, no prompt, no permission toggle. |
| Growth | Geometric (1→2→4→8) | Arithmetic (+6–9 cols per frame) until real terminal width is reached |
| Status on v2.1.116 | Closed as fixed | Still reproduces. Confirmed by @konepone, @limikelove200-lgtm, @ventilla, @charlie-elisity, @shinobu1729. |

#46834 re-emits the entire transcript on relayout — here only the welcome banner stacks, before any transcript exists. #46499 requires a prompt — here the cascade fires before any input. #46462 is closed and was about resize-driven enlargement.

Clean bisection (single variable):

• claude --dangerously-skip-permissions in 80-col → cascade
• claude (no flag) in 80-col → no cascade
• claude --dangerously-skip-permissions in ≥155-col → no cascade

The only delta between the flagged and unflagged paths is the footer ⏵⏵ bypass permissions on (shift+tab to cycle). U+23F5 has East_Asian_Width=A (ambiguous) and Emoji_Presentation=No — measured as 1 cell by string-width / Ink, rendered as 2 cells by macOS Terminal's emoji fallback. The 2-cell undercount overflows, the startup layout retries wider, still wrong, retries wider — the observed arithmetic growth.

Same class as #30471 and #46909. Whatever #47235 patched lives in the SIGWINCH handler; this bug is in the first-paint pass, upstream of it.

Please remove the duplicate label. One-line fix: replace ⏵⏵ with >>, or append \uFE0F after each ⏵.

+1 — observing a partial-fix variant of this on 2.1.119 / macOS Terminal.app (Darwin 24.6.0, Apple Silicon).

The full TUI no longer stacks (logo+header+cwd+status seem to redraw correctly in v2.1.119), but a single ghost input box
echoing the previous prompt is still rendered below the splash/version footer and persists across turns. Looks like the same
SIGWINCH/redraw root cause described here, just a milder leftover after whatever changed between 2.1.104 and 2.1.119.

Symptoms on 2.1.119:

• Single duplicate input box, not full TUI stacking
• Triggered on every prompt submit (not specifically window resize)
• Cleared temporarily by /clear, Ctrl+L, or window resize — reappears on next turn
• Window size when reproduced: 72×40
• No tmux/screen, TERM=xterm-256color, zsh

Filed as #54050 — closing as duplicate of this since the root cause looks shared. Tracking under this issue going forward.

Subscription: Claude Max. Will try CLAUDE_CODE_NO_FLICKER=1 workaround mentioned in OP.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.