[META] Copy/paste is broken across all surfaces — tracking issue for 42 open copy/paste issues

Status Open

Reported on v2.1.167

Maintainer reply None cached

Activity 4 comments · opened Jul 26, 2026

Summary

Copy/paste in Claude Code is unreliable across every surface (TUI, VS Code extension, desktop app), and the problem has been reported continuously since the earliest issues on this tracker (#5512, #6827). There are currently 42 open issues describing what is really a handful of root causes in the renderer and clipboard handling. This meta-issue consolidates them so the problem can be prioritized and tracked as one systemic defect rather than 42 papercuts.

The common thread: the TUI renders for visual appearance, not for selection/copy fidelity. Text that looks right on screen round-trips through the clipboard as broken text — hard-wrapped, gutter-indented, whitespace-padded, or encoding-corrupted — and mouse capture frequently prevents selection in the first place. This affects users dozens of times per day, and several variants break /login OAuth flows outright.

Root causes and their issues

1. Hard line breaks inserted at render width (~80 cols)

The renderer inserts literal \n at word-wrap boundaries instead of letting the terminal soft-wrap, so copied prose/code contains spurious newlines.

#6827 — hard line breaks at ~80 chars in VS Code extension
#13378 — 2-space indent + hard wrap at 80, no way to configure it off
#15199 — formatting artifacts break copy/paste, workarounds waste tokens
#22073 — newlines instead of proper wrapping
#48037 — hard line breaks at every wrapped line
#43113 — [feature] emit long lines and let the terminal emulator wrap

2. Gutter indentation, padding, and decoration included in selections

The 2-space left gutter, Ink's space-padding (instead of \x1b[K clear-to-EOL), and blockquote glyphs are all part of the on-screen text, so they come along with every copy.

#18170 — unwanted indentation and trailing spaces
#23014 — trailing whitespace padding and ANSI escapes (Ink space-padding vs \x1b[K)
#37796 — 2-space leading indentation in copied text
#69515 — multi-line copies broken by UI tab indentation
#75221 — [feature] option to strip/disable the left gutter

3. Mouse capture breaks native terminal selection

Mouse reporting is enabled by default, so click-drag selection, right-click paste, and tmux copy-mode stop working; the alternate-screen/fullscreen renderer makes scrolled-out text unreachable entirely.

#71826 — mouse capture on by default breaks native selection and copy
#68602 — mouse reporting interferes with copy-paste and scrollbar
#66056 — right-click paste broken since ~2.1.167 (Shift+right-click workaround)
#69704 — Ctrl+Shift+C / right-click copy broken in response text
#62462 — cannot copy from responses in GNOME Terminal (Ubuntu 24.04)
#60185 — new scroll UI breaks tmux copy-mode workflow
#70857 — fullscreen (alt-screen) mode: can't select/copy the login URL
#80262 — cannot select/copy output once scrolled out of the viewport
#71698 — text unselectable after an Edit-tool diff block
#74420 — unable to copy on terminal
#74597 — paste broken in Terminal.app

4. Clipboard encoding corruption (UTF-8 / OSC 52 / system clipboard)

Non-ASCII text is corrupted on the way into or out of the clipboard; in the worst case the fullscreen renderer corrupts the system-wide macOS clipboard for all apps.

#72455 — fullscreen renderer corrupts the SYSTEM-WIDE macOS clipboard
#65394 — pasted Korean/CJK decoded as Latin-1 on Windows (fullscreen renderer)
#66098 — OSC 52 copy corrupts multi-byte UTF-8 (Cyrillic)
#79482 — /copy writes the clipboard as Latin-1, non-ASCII pastes as mojibake
#75380 — copied text has UTF-8 mojibake (— becomes ‚Äî) plus gutter glyphs
#67576 — OSC 52 copy never reaches RDP clipboard redirection (Windows conhost)

5. Wrapped URLs break authentication flows

Hard-wrapping (root cause 1) applied to OAuth URLs makes them unclickable or truncated, which breaks /login and MCP auth — not a papercut, a functional failure.

#72628 — OAuth URL wraps in WebStorm terminal → "Missing state parameter"
#79957 — /login / claude auth login URL not clickable due to line breaks
#73114 — MCP OAuth authorization URL wraps; Ctrl+click opens a truncated link

6. Paste-side input bugs

#73098 — vim editor mode: pasted line breaks become literal j when paste isn't bracketed
(#65394 and #74597 above also have paste-side components)

7. Silent content loss when copying

#78101 — code blocks silently drop lines containing certain XML tags (rendering + copy)
#79961 — VS Code extension strips whitespace at inline element boundaries when copying
#80127 — VS Code extension: /compact summary output is not copy/paste-able

8. Missing copy affordances (feature requests that exist because of 1–7)

Many of these requests are workarounds users are begging for because raw selection is broken:

#5512 — /copy command to copy messages to the clipboard
#68935 — keyboard shortcut to copy the prompt input buffer
#74185 — desktop app: copy button at the bottom of long code blocks
#77029 — sticky copy button, always visible on long code blocks
#77936 — per-message copy button in the VS Code extension
#75155 — selective text copy within messages (mobile + desktop)
#70683 — RTL input support + copy button for responses

Impact

Daily, repeated friction for essentially every terminal user: copying anything multi-line requires manual cleanup of newlines and gutter indentation.
Broken /login and MCP OAuth flows (category 5) block users from using the product at all in affected terminals.
Data integrity failures (categories 4 and 7): copied text is silently different from displayed text, which is worse than an error.
The volume of duplicates suggests users can't find a canonical issue to follow — another cost of not having a tracking issue.

Suggested direction

Treat copy fidelity as a renderer requirement: what the user selects must round-trip byte-for-byte. Concretely: clear-to-EOL instead of space padding, no hard newlines inside logical lines (or an opt-out per #43113), gutter as non-copyable margin or removable via config (#75221).
Make mouse capture opt-in or auto-yielding, so native terminal selection works by default (#71826).
Fix clipboard encoding once, centrally — UTF-8 everywhere for OSC 52 and /copy (#79482, #66098), and audit the fullscreen renderer's clipboard interaction on macOS (#72455).
Never hard-wrap URLs (#72628, #79957, #73114) — cheap fix, disproportionate impact.
Keep this issue open as the tracking issue and label the 42 issues above as sub-issues/duplicates where appropriate.

---

This meta-issue was compiled from the open issue tracker on 2026-07-26; all 42 linked issues were open at that time.

View original on GitHub ↗

3 Comments

annexiao · 29 days ago

Draft comment for anthropics/claude-code#81472

Post as a comment on the META tracking issue. Paste from the line below.

---

Thanks for compiling this. My #79482 is in your category 4, and I have measurements that I think collapse part of that category rather than just add to it.

Category 4 may be two root causes, not six

Three of the six issues in "Clipboard encoding corruption" share a necessary condition that is not mentioned in the grouping: the fullscreen renderer. All three are fixed by /tui default.

| Issue | Direction | Platform | /tui default fixes it |
|---|---|---|---|
| #72455 | both, system-wide | macOS, Terminal.app | yes (stated in the report) |
| #65394 | paste in | Windows, WSL | yes (stated in comments; does not apply to claude agents, which forces fullscreen) |
| #79482 | copy out via /copy | macOS, VS Code terminal | yes (measured, table below) |

The remaining three in that category (#66098, #67576, #75380) are OSC 52 or gutter issues and look genuinely separate.

To be precise about what is measured and what is not: the fullscreen dependency is measured independently in all three reports, and the byte-level transformation in mine is measured. That these are one defect rather than three defects sharing a trigger is an inference from the correlation, not something I verified. The three are different code paths (paste in, system clipboard, /copy out).

A second variable that may explain why these reports disagree

Fullscreen alone is not sufficient in my case. It breaks only when the renderer is fullscreen and the copied text contains box-drawing or symbol characters (U+2500 range, U+2605). Either one alone is fine.

tui         source   clipboard   latin-1 prediction   result
fullscreen   2372      4109            4109           BROKEN
fullscreen   2899      2899             -             OK
default      2876      2876             -             OK
fullscreen   2876      5321            5321           BROKEN

Both broken runs land exactly on len(raw.decode('latin-1').encode('utf-8')). Length is not the variable.

If the same two-condition gate holds in the other reports, it would explain why some users on fullscreen report no problem at all: their text happened to be free of those characters. It is worth asking the reporters on #72455 and #65394 whether their failing samples contained box-drawing characters.

A falsifiable test for your suggested direction 1 and 3

Your direction 1 asks that copy round-trip byte for byte. That can be asserted directly, because /copy already writes a clean UTF-8 dump file next to the clipboard write:

/copy
pbpaste | wc -c
wc -c /tmp/claude-*/response.md   # must be equal

As a unit test: clipboard_bytes == dumpfile_bytes for any string containing at least one character above U+007F, run once per renderer mode. That single assertion covers #79482 and, if the merge above holds, #72455 as well.

Two housekeeping notes on the tracker itself

Three of the 42 have closed since you compiled on 2026-07-26:

#69515 and #68935 closed
#65394 closed on 2026-07-28 by the inactivity bot, not_planned, two days after you filed this. It had a has repro label, four substantive comments, and confirmations on Windows, WSL, and Linux.

That last one is direct evidence for your point about duplicates and lost issues. My own #79482 exists only because its two predecessors (#66065, #66421) went the same way: closed by the bot with "please open a new issue if this is still relevant", never fixed.

Also, only 12 of the 42 carry the has repro label: #6827, #15199, #22073, #23014, #37796, #66056, #69704, #72455, #65394, #66098, #79482, #73098. If triage runs on that label, those 12 are the ones with a ready path to a regression test.

annexiao · 29 days ago

Three of the six issues in your category 4 may be one bug. #72455, #65394 and mine (#79482) are all fixed by /tui default, on three platforms and three separate code paths (paste in, system clipboard, /copy out). The fullscreen renderer is the shared condition, and the grouping doesn't say so.

Calling them one defect is an inference. What I measured is that fullscreen is required in my case.

Both conditions have to be present. /copy breaks when the renderer is fullscreen and the copied text contains box-drawing or symbol characters (U+2500 range, U+2605). Either one alone gives a clean clipboard. Numbers are in #79482.

That two-condition gate would explain why the reports in this category contradict each other. A user on fullscreen whose text happened to be plain ASCII sees nothing wrong, and says so.

So the cheapest test is to ask the reporters on #72455 and #65394 whether their failing samples had box-drawing characters. One answer confirms the merge or kills it.

One more thing for your point about issues getting lost. #65394 was closed by the inactivity bot on 2026-07-28, two days after you filed this. It had a has repro label and confirmations on Windows, WSL and Linux.

filteredwaterdev · 26 days ago

One surface missing from this meta-issue is the claude.ai web UI — not Claude Code itself, but the same underlying web architecture and a directly related failure category. A rendering update introduced message-level virtualisation to the conversation list, meaning only messages near the current viewport exist in the DOM at any given time. This silently breaks clipboard copy, arbitrary drag selection, Select All / Copy, Save Page As, and Print to PDF, the same root cause as category 3 here, applied to the browser DOM rather than the terminal rendering layer. Operations appear to succeed but the OS has only whatever fragment happened to be mounted at that moment.

This has been present since approximately June 2026 and affects paying web UI users with no acknowledgement or workaround from Anthropic. Full bug report filed to this repo in the absence of a dedicated web UI tracker: https://github.com/anthropics/claude-code/issues/83456

Showing cached comments. Read the full discussion on GitHub ↗