[BUG] Selecting + copying assistant output from terminal scrollback silently drops characters mid-word

Status Open
Reported on v2.1.201
Maintainer reply ✓ Yes — bcherny
Activity 4 comments · opened Jul 6, 2026
💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Summary

The TUI renders assistant output completely and correctly on screen, but when I manually select that text with the mouse and copy it out of the terminal, the copied/pasted result is missing spans of characters — often mid-word or around line boundaries. The on-screen text is intact; only the copied text is corrupted. This is different from copy-paste failing entirely (#66192, #71823) or losing rich clipboard flavors (#72565, no public.html) — here plain-text copy succeeds but with chunks silently deleted.

Environment

  • Claude Code: 2.1.201
  • Terminal: Apple_Terminal 455.1 (TERM=xterm-256color)
  • macOS: 15.7.7 (24G720)
  • LANG=en_US.UTF-8

Repro

  1. Have the assistant print a multi-paragraph message (long enough to soft-wrap several lines).
  2. Mouse-select the rendered message in the terminal and copy it.
  3. Paste into another app (Slack, editor).

Expected

Pasted text == the text shown on screen.

Actual

Pasted text is missing spans, frequently at/near soft-wrap points. Example — the message displayed on screen in full, but pasted as (corruption ⟪…⟫ marks where characters were dropped):

  • Our real data was⟪ under 5⟫00 MB).
  • To delete those junk logs,⟪ the database needed a little⟫ free space to work with — and there was⟪ ⟫none.
  • freed ~295 GB (disk went from 100% full to under 1%). T⟪hen cleaned up the smaller⟫ junk logs and set a 14-day auto-expiry on⟪ ⟫all of them

So whole word-runs (under 5, the database needed a little, hen cleaned up the smaller) and single spaces (was none, on all) both get dropped. The dropped spans cluster around where lines wrap, which suggests the selection is reading a repainted/reflowed scrollback buffer rather than the logical text.

Notes

  • Reproduces across separate copies (not a one-off clipboard glitch); the on-screen render is always correct.
  • Possibly related to the TUI repaint/reflow family (#32908 dropped chars in display, #72501 repaint corruption) but the distinguishing factor here is that display is correct and only the copied buffer is lossy.

— Claude

View original on GitHub ↗

3 Comments

bcherny collaborator · 14 days ago

Thanks for the detailed report. I tried to reproduce on the released 2.1.233 build on macOS: I ran Claude Code (default, non-fullscreen mode) inside a 100-column terminal, had it stream a three-paragraph answer that soft-wrapped many lines, then dumped the terminal's screen/scrollback buffer and compared it against the actual response text. Every paragraph was fully intact in the terminal buffer — no missing words or spaces at wrap points. I wasn't able to drive Terminal.app's mouse selection + copy headlessly, so I couldn't test the exact copy step you describe, and I can't rule out a Terminal.app-specific issue.

To narrow it down, could you share:

  1. Whether it still happens on the current version (claude update, then retry — 2.1.233 or newer).
  2. Whether you're in fullscreen mode (/tui) or the default mode.
  3. Whether the same paste is lossy from iTerm2 (or any other terminal), or only Terminal.app.
  4. Whether it also happens with CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 claude.
  5. claude doctor output and your terminal width (tput cols).

If you can, a small screenshot of the selection plus the pasted text side by side would help a lot.

🤖 Generated with Claude Code

github-actions[bot] · 14 days ago

We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.

Storicoselfstorage · 10 days ago

Arriving here from #84772 (closed as duplicate of this one) — same symptom, and I hit it regularly, so here are answers to the repro questions from my setup in case they help narrow it down:

  1. Version: last confirmed repro on 2.1.235 (currently on 2.1.237, will report if it recurs there).
  2. Mode: fullscreen ("tui": "fullscreen" in settings.json) — this may be the missing repro condition, since the attempt above was in default non-fullscreen mode and fullscreen uses the alternate screen buffer.
  3. Terminal: Apple Terminal 455.1, TERM=xterm-256color, 80 cols, macOS 15.6.1, LANG=pl_PL.UTF-8. Haven't tested iTerm2 or CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 yet.

One observation that may matter: in every occurrence on my side the text was dense with multibyte Polish diacritics (ą, ł, ż, ó), and the dropped span starts at or right after a non-ASCII character. Example from #84772: on-screen stanowisk spawalniczych pasted as stanowisspawalniczych (dropped k mid-word, plus a trailing comma). A repro attempt with multibyte-heavy text in fullscreen mode might trigger it where plain-ASCII English in default mode didn't.

Happy to provide more samples or run specific experiments.

Showing cached comments. Read the full discussion on GitHub ↗