[BUG] Copy-paste does not work

[nvankita]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

• Version: 2.1.168
• Terminal: Termius on Mac, SSH to remote Linux
• Behavior: copy-paste within Claude session stopped working after recent update; OSC 52 messages appear but clipboard not set

What Should Happen?

Simple CMD+C (copy) CMD+V(paste) should work

Error Messages/Logs

sent # chars via OSC 52. if paste fails, hold shift (option in iTerm2, Fn in terminal.ap ) while selecting for native copy.

Steps to Reproduce

Simply copy & paste some text within the same claude session

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.168

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[yurukusa]

The detail that "OSC 52 messages appear but the clipboard isn't set" actually localizes this well — and it points away from Claude Code being able to fix it directly, so it's worth understanding why.

What OSC 52 is doing here: you're SSH'd into a remote Linux box, so the remote process (Claude Code) can't touch your Mac's clipboard directly. OSC 52 is the escape sequence by which the remote program asks the terminal emulator (Termius, running locally on the Mac) to write the data into the local clipboard. So the chain is: Claude Code emits OSC 52 → Termius must recognize it and honor a clipboard-write. "Messages appear but clipboard not set" means the first half works and Termius isn't applying the write — which makes this a terminal-side capability, not something Claude Code controls once it has emitted the sequence.

Isolate it in 10 seconds (rules Claude Code out entirely): in the remote shell, outside Claude Code, run:

printf '\033]52;c;%s\007' "$(printf 'osc52-test' | base64)"

Then try to paste on your Mac. If you get osc52-test, OSC 52 works and the issue is something Claude Code-specific (format/size). If you get nothing, Termius is not honoring OSC 52 clipboard-writes at all, and no change in Claude Code will fix the copy path — it's a Termius setting/limitation.

Most likely causes, given it's a regression:

• Many terminals gate OSC 52 write behind a setting (or disable it by default, since "let remote hosts write your clipboard" is a security surface). Check Termius for an OSC 52 / clipboard-sync / "allow clipboard access" option and enable write. The regression is consistent with Claude Code having switched its copy path to rely on OSC 52, which your Termius config doesn't permit.
• Size limit: OSC 52 payloads are capped in many terminals (often tens of KB). If small copies work but large selections silently fail, that's the cap, not a total failure.

Working around it now: the fallback in your own log is the reliable one — use the terminal's native selection, which bypasses OSC 52 entirely: hold Fn while selecting in Terminal.app (Option in iTerm2; Termius has its own modifier — usually Shift or a "selection mode"), then ⌘C. That copies via the local terminal, not the remote escape sequence, so it works regardless of OSC 52 support.

Honest caveat: I can't see Termius's internals or the exact Claude Code version change, so I won't assert the precise regression — but the printf test above will tell you definitively whether the fault is in the terminal (OSC 52 not honored) or upstream, which is the thing to attach to this report either way.

[aslom]

Same symptom here on plain iTerm2 (no tmux, no SSH, no IDE — directly in an iTerm2 shell).

Environment

• Claude Code: 2.1.168 (broken)
• Last-known-good: 2.1.142 (copy-on-select worked fine)
• Terminal: iTerm2 on macOS
• Renderer: fullscreen / no-flicker (the current default)

Repro

1. Select text in the Claude Code TUI by click-dragging.
2. Claude shows the "copied … via OSC 52" confirmation.
3. Paste anywhere → nothing. The pasteboard was never updated.

What I found

• The OSC 52 write is silently dropped because iTerm2 blocks apps from
  writing the clipboard by default. Enabling Settings → General → Selection →
  "Applications in terminal may access clipboard" (or running /terminal-setup)
  makes Claude's copy-on-select and /copy reach the pasteboard again.
• Manual Option+drag selection always works, because that's iTerm2 doing
  the copy itself and bypasses the app's OSC 52 path entirely.
• CLAUDE_CODE_DISABLE_MOUSE=1 and CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1
  had no effect for me — the fullscreen renderer and its OSC 52 copy
  stayed active regardless of how I launched.

This is a clean 2.1.142 → 2.1.168 regression. It lines up with the copy-on-select /
OSC 52 rework that started around 2.1.153 (which also shipped a documented
copy-on-select-to-clipboard regression). The fix that would help: detect when
OSC 52 isn't honored and fall back, or surface the iTerm2 permission requirement
instead of reporting a successful copy that never happened.

[jrbissell]

same issue on GNOME Terminal / Linux variant (Shift+right-click context menu stopped working),

[semyon-levin-workato]

Same with WizTerm terminal on MacOS (via Command+C)

[semyon-levin-workato]

Adding "tui": "default" to ~/.claude/settings.json fixes the issue.

[QuintinWillison]

I have Claude Code installed within a Ubuntu VM instance provided by Lima (my host is macOS) and I use the macOS-built-in Terminal app. Was encountering this issue this morning when I tried to 'quickly' copy something out of my terminal window.

I've added the following to my environment and now things are stable again, I didn't need or want any mouse-related features for a REPL/CLI-tool anyway 🤷:

# Because Claude Code hijacks OSC 52 making normal Terminal select/copy workflow break.
export CLAUDE_CODE_DISABLE_MOUSE=1

[pkousha]

+1 on the issue.
In mac OS terminal the cmd+shift+C is reserved for modifying colors and it is hard coded. changing the keybindings also didn't help.

[nameliu0523]

Version 2.1.172, there are still issues in the Deepin Linux environment. I asked CC, and the solution he provided was feasible: You can hold down the Shift key and then use the mouse to select the text. This will bypass the custom binding of the terminal and use the native copy function of the terminal emulator.

[zoratu]

Adding "tui": "default" to ~/.claude/settings.json fixes the issue.

Adding this to my settings file fixed it without even needing to restart my sessions.