Conversation rendered/duplicated multiple times in terminal (v2.1.112)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/46834
2. https://github.com/anthropics/claude-code/issues/49086
3. https://github.com/anthropics/claude-code/issues/48318

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

I've also encountered this issue

Same. Getting repeated chunks, saw it in two separate threads. (even in .116)

+1, confirming still reproduces on Claude Code 2.1.116.

Environment

• Claude Code: 2.1.116
• OS: macOS 26.2 (Darwin 25.2)
• Node: v24.11
• Model: Opus 4.7 1M
• Terminal: Ghostty

Symptom
Prose paragraphs (not code, not structural output — plain multi-line prose with bullets) rendered verbatim 6× consecutively within a single session. Identical word-for-word, including punctuation and line breaks. No visible tool-use boundary where the duplication starts; no retry in the CLI; no tool call in between. The rest of the session scrolled normally before and after.

This is distinct from #50689 (code-structural duplication) and #50689's repeated-pattern hypothesis — the duplicated content was pure prose with no repeated structural markers that a model could plausibly emit twice by accident.

Onset
Within the last few hours as of 2026-04-21, affecting multiple independent shell-launched sessions (different cwds, different projects) simultaneously. That argues against per-session state and toward a client-side renderer issue or a recent silent auto-update. Surge of related reports filed on this repo today (repetition, duplication, tight-loop freezes on 2.1.116) is consistent.

No recent local changes (hooks, shell wrappers, settings.json) can explain it — behaviour is present in sessions started from fresh shells with only stock config.

I get this on mac, irrespective of whether claude is running in VS Code integrated terminal, or iTerm2, the same output is in the window 5 or 6 times.

Confirming I have the same issue with the following environment:

Claude Code: v2.1.123
OS: macOS 14.6 (23G80)
Node: v24.12.0
Model: Opus 4.7 1M
Terminal: cmux

The content duplication mainly occurs in conversation history scrollable area.

I've also encountered this issue very frequently with the following environment:

• Claude Code 2.1.138
• Noticed regressions particularly around when /recap was added
• OS: macOS Tahoe 26.4.1
• Terminal: Ghostty 1.3.1

Adding a reproduction data point with transcript-level verification, since this issue is light on repro detail.

Environment: Claude Code 2.1.218, Windows 11 Home, Windows Terminal (WT_SESSION set, TERM=xterm-256color), interactive CLI session.

Symptom: The most recent assistant text block renders twice in scrollback — the first copy truncated mid-line, the second complete. Observed twice in one long session. The conversation itself is unaffected (verified below); this is purely display.

Correlation (both occurrences):

• The duplicated block was a long, multi-line markdown message (bullets, em-dashes, wrapped lines).
• Within 2–3 seconds of the text finishing, the renderer had to append something directly beneath it — in one case a tool call starting (text at 00:12:35 → tool_use at 00:12:38), in the other case Stop-hook system output (text at 23:55:53 → system rows at 23:55:55).
• The session had heavy mid-turn interleaving: queued user messages typed while the assistant was streaming (queue-operation rows in the transcript) and background task-completion notifications.

Transcript verification (why we're confident it's render-side): We grepped the session JSONL for the duplicated sentences. Each appears exactly once in an assistant message.content text block. The additional occurrences in the file exist only in user / queue-operation / attachment rows — i.e., the user pasting the doubled screen back into chat. Single emission, double paint.

Reading of the mechanism: Consistent with #52866's description of the TUI re-rendering "from scratch on each new chunk/result instead of appending." The truncated first copy suggests the repaint's erase pass underestimates the height of the previous wrapped block (long lines + wide punctuation at this window width), so part of the stale frame survives above the freshly drawn one.

Happy to provide additional environment detail or run a candidate build against the same workflow.