/copy writes the clipboard as latin-1, so non-ASCII output pastes as mojibake (still broken in 2.1.215)

Update: I have a deterministic repro now. It is not intermittent, it needs two conditions at once, which I think explains why the earlier reports on this disagree with each other.

It breaks only when the fullscreen renderer is active AND the copied text contains box-drawing / symbol characters (U+2500 range, U+2605). Either one alone is fine.

| | text has box-drawing / ★ | text has none |
|---|---|---|
| "tui": "fullscreen" | BROKEN (2 for 2) | OK |
| "tui": "default" | OK | OK |

Every run measured the same way: /copy writes a dump file, then compare pbpaste | wc -c against wc -c on that file, immediately, before anything else touches the clipboard.

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')), so the corruption is the same latin-1 round trip described in the original report. The dump file is clean UTF-8 in every case, including the broken ones, so only the clipboard write is affected.

Length is not the variable. The longest sample (2899 bytes) was the one that came out clean; it just had no box-drawing characters in it.

What I could not separate: both broken samples contained U+2500-range box-drawing and U+2605 together, so I cannot say which of the two triggers it, or whether it is the whole ambiguous-width class. The broken sample had 174 box-drawing characters and 6 symbols. Em dash (U+2014) appears in a clean sample, so that one is not enough on its own.

Guessing at the mechanism, and this part is a guess: the fullscreen renderer has to compute display width for every character itself, where the default renderer leaves that to the terminal. Ambiguous-width characters are exactly the ones that path has to make a call on, so a bug there could corrupt the buffer that later feeds the clipboard while the on-screen rendering still looks correct. That matches what I see, since the text displays fine and only the copy is wrong.

If that is right, this and #66269 are the same bug seen from two sides. #66269 reported the renderer as the cause and found "tui": "default" fixes it; other reporters on fullscreen presumably were copying text without those characters and saw nothing wrong. The interaction would explain both.

Environment unchanged from the original report: Claude Code 2.1.215, macOS 26.5.2 arm64, TERM_PROGRAM=vscode, LANG=en_US.UTF-8.

Repro, if useful:

1. /tui fullscreen
2. get assistant output containing a box-drawing rule (a run of ─) plus CJK or any non-ASCII
3. /copy
4. pbpaste | wc -c vs wc -c /tmp/claude-*/response.md, they differ, and the clipboard size equals the latin-1 round trip of the file
5. /tui default and repeat the same steps, sizes now match

Could not reproduce on v2.1.233 (macOS 26, arm64) in iTerm2 and in tmux inside iTerm2, with the fullscreen renderer on and text containing CJK + a run of ─ box-drawing + ★.

Steps:

1. Start claude with /tui fullscreen, ask for a reply containing 好了，给你两条路 ★ ─────────── café — résumé.
2. Run /copy.
3. Immediately compare pbpaste | wc -c with wc -c /tmp/claude-*/response.md.

Observed: both 81 bytes, cmp reports the clipboard and the dump file identical, paste is correct.
Expected (per the report): clipboard larger than the file, latin-1 mojibake on paste.

Assessment: this looks like a genuine bug, but with two halves. The byte pattern you measured (each UTF-8 byte re-encoded as one Latin-1 character) is exactly what a known bug in the terminal-side OSC 52 clipboard handler shipped by VS Code 1.123 and 1.124 produces (fixed upstream in VS Code 1.125; forks such as Cursor pick that up on their own schedule, and TERM_PROGRAM_VERSION=3.11.13 is a Cursor version). That is why it never shows up in iTerm2/tmux here. On our side, /copy on a local macOS session writes the clipboard twice: once through pbcopy (correct, and what the docs describe as the local path — https://code.claude.com/docs/en/fullscreen) and once through an OSC 52 escape sequence as a safety net. In a terminal with that decoder bug the OSC 52 write lands after pbcopy and overwrites the good result with the mangled one, which matches everything you saw: the dump file is fine, pbcopy < response.md fixes it, and ASCII-only text is unaffected. The fullscreen-vs-default and box-drawing correlations are most likely timing (a heavier redraw shifts when the terminal processes the OSC 52 write relative to pbcopy) rather than a renderer encoding bug. Claude Code already shows a warning for VS Code 1.123/1.124, but its version check does not recognise Cursor's version numbers, so you got no warning either. Two things would fix this properly on our side: skip the OSC 52 write locally when a native clipboard tool already succeeded on a VS Code-family terminal, and extend the warning to Cursor. In the meantime, a current VS Code build (1.125 or later) or Terminal.app/iTerm2 should give clean pastes; if you can confirm it is clean there, that pins it to the terminal decoder plus our double write.

🤖 Generated with Claude Code

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.