[BUG] Copy-paste does not work

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.

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.

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

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

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

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

+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.

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.

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.

same on popos, v annoying

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.

Thanks, this worked for me as well.

This completely breaks login on a headless server via ssh over macos terminal and turns this into a miserable existance.

Let me spell out the root cause for anyone triaging, since it's not complicated: this is OSC 52. The c to copy feature writes the URL to the clipboard via the OSC 52 escape sequence. macOS Terminal.app doesn't implement OSC 52 — never has — so the sequence gets silently discarded. iTerm2 supports it, Terminal.app doesn't. That's the entire bug.

So let's recap what actually shipped: a "copy" button whose one and only mechanism is silently dropped on the floor by the default terminal on macOS, with no error, no fallback, no feedback — and it fails hardest in the headless-over-SSH flow, which is the exact scenario where copying that URL is the only way through because there's no local browser. You built a button that lies. It tells the user "press c," the user presses c, and the tool just... pretends. A feature that fails silently is strictly worse than no feature at all, because now I'm sitting here mashing c at an unwrappable wall of URL wondering if I've lost my mind.

Here's the part that really gets me. This is a solved problem. Detecting terminal clipboard support, or just printing a fallback when it's not there, is not some unsolved frontier of computer science. AWS figured it out. OpenAI figured it out. OpenRouter figured it out. DeepSeek figured it out. Every one of these CLIs degrades gracefully when the clipboard isn't reachable — they print the URL, they offer a fallback, they don't gaslight you. And yet the self-styled largest AI company on the planet ships a login flow that can't clear a bar a weekend project clears on day one.

The fix is trivial. Pick one:

If OSC 52 isn't acknowledged (or the terminal is a known-broken one like Terminal.app), print a message instead of silently no-op'ing.
Document it inline: c to copy (requires OSC 52, e.g. iTerm2).
Give headless users a real escape hatch: --print-url, dump to a file, or a loopback-tunnel login so there's no clipboard to fail in the first place.
Any intern can land this in an afternoon. The fact that it's still here, in auth, in the most common terminal on macOS, tells me something about the QA culture — and as someone eyeing the IPO, "couldn't be bothered to test the login button on the default Mac terminal" is not the signal that inspires confidence in writing a check.

Fix the silent failure. That's the whole ask.

it's not even only what @VincentJGeisler describes, it basically makes it impossible to do any native terminal copying, it deselects the text any time i try to right click

@cagostino you are right.. I was focused on. my edge of the problem. This is facepalm worthy bad bug with much wider implications.

Hello, I'm encountering the same issue on Ubuntu 24.04, on Terminator. I have to right-click 3 times for the dropdown to show and it therefore de-selects my selection before the dropdown is displayed so Copy is disabled when the drop down opens.
I also can't use the classic Ctrl+Shift+C, it deselects my selection.
I can however properly copy on anything outside of claude code in my terminal.
It does show me the copy status line and tells me to press Shift, but I'm already pressing Shift.

Does anybody has any reliable workaround that does not require modifying ~/.claude/settings.json to add "tui": "default" ? I use sandboxes and has many .claude/settings.json create din new sandbox homes ...

environment variable workaroudn export CLAUDE_CODE_DISABLE_MOUSE=1 doe snot seem to work in 2.1.168?

As a workaround I have now skill to /add-tui-default

~~~~
---
name: add-tui-default
description: >
Enable the default TUI (terminal UI) mode in Claude Code. Use /alek-tui to
add "tui": "default" to .claude/settings.json.
user-invokable: true
allowed-tools:

• Read
• Edit
• Write

---

TUI: Enable Default Terminal UI

Configure Claude Code to use the default TUI (terminal UI) mode by setting "tui": "default" in project settings.

Procedure

Step 1: Read current settings

Read .claude/settings.json in the project root. If it doesn't exist, start with an empty JSON object {}.

Step 2: Configure the tui setting

Set the tui key in the settings JSON to "default":

{
  "tui": "default"
}

Preserve all other existing keys in the settings file. Only add or overwrite the tui key.

Step 3: Write the updated settings

Write the updated JSON back to .claude/settings.json.

Step 4: Confirm

Tell the user the TUI mode is configured. It will take effect on the next session or after reloading settings.
~~~~

For me, on plain Ubuntu Terminal, in fullscreen mode, shift-ctrl-c, mouse clicks etc. nothing works. The only way I have found to copy an item from the terminal is:

• shift and select text with mouse (double click or pan text area), the selected area is outlined differently than without shift
• then shift-ctrl-c

@gom59 thanks, this works.

it is phenomenal that this is unresolved. in my case ubuntu 24.04 is the environment. the worst thing is that the claude code interface advertised this "fullscreen" as something to try out - as if it would be easy and obvious how to revert if you don't like it. it turned out to be anything but.

There's a quicker way to achieve the same results (at least this is what worked for me)

I often SSH connect to my home Mac and as my needs are pretty basic, simply rely on the default Terminal.app that comes as standard.

On that exact setup this morning, in an existing CC session I ran '/tui default' which reloaded my session and asked me for feedback on why I have chosen to revert bak to the default display.

After this change I can confirm that my usual [cmd]+C behaviour has been restored.

In my setup at least the failure appears when using tui fullscreen mode - see below. Switching to tui default clears it:
Title: OSC 52 clipboard write fails silently in fullscreen TUI mode on macOS Terminal.app

Body:

Bug Description

When "tui": "fullscreen" is set in settings.json, Claude Code automatically sends OSC 52
clipboard write sequences when rendering output (e.g. code blocks). On macOS Terminal.app
these sequences are silently ignored — the clipboard is never updated — but Claude Code
still shows "sent xxx characters via OSC 52", making it appear the copy succeeded.
Copy-paste is completely broken.

Steps to Reproduce

1. Set "tui": "fullscreen" in ~/.claude/settings.json
2. Open Claude Code in macOS Terminal.app
3. Ask Claude to output a code block
4. Observe "sent xxx characters via OSC 52" appears automatically (before pressing

anything)

1. Press Cmd+V — clipboard is empty

Expected behavior: OSC 52 write succeeds, or Claude Code detects it's unsupported and
falls back gracefully.

For me, switching the the old renderer works:

/tui default

Jesus Christ. Breaking someone's copy/paste is insane.

export CLAUDE_CODE_DISABLE_MOUSE=1

This worked.

Same for me on iTerm2 macOS (tmux over ssh to linux)

• Works when I launch a claude code session
• Breaks when I press left arrow to switch to agents view and go back to the session. Copy paste no longer works, just print this at the bottom: _"sent 36 chars via OSC 52 • if paste fails, hold Shift (Option in iTerm2, Fn in Terminal.app) while selecting for native copy"_

Fedora 44 gnome terminal, give me back my ctrl + c 🙄