[BUG] Copying to clipboard prefers wl-copy

Same root cause, much worse impact on GNOME 50 (mutter 50.3) — a single /copy permanently breaks the system clipboard.

Confirming this with a far more severe symptom. The "taskbar entry for a split second" is wl-copy creating a real xdg_toplevel to grab keyboard focus (needed for a valid set_selection serial, since mutter exposes no data-control protocol). On GNOME 50 / mutter 50.3, that wedges the compositor's wl_data_device selection permanently for the rest of the session.

After one /copy: no GUI app can read or write the CLIPBOARD (verified with gedit, Chrome, Vivaldi). set_selection is silently ignored — mutter re-sends the current selection instead of sending cancelled, so orphaned wl-copy daemons pile up (34 after a few hours). WAYLAND_DEBUG shows the surface is created but never receives wl_keyboard.enter:

-> wl_compositor#4.create_surface(new id wl_surface#14)
-> xdg_wm_base#8.get_xdg_surface(new id xdg_surface#15, wl_surface#14)
-> wl_data_device#3.set_selection(wl_data_source#12, 10550)
<- wl_data_device#3.selection(wl_data_offer#...)   // current selection re-sent, no `cancelled`

What makes it hard to spot: PRIMARY still works (different protocol, zwp_primary_selection_device_manager_v1), so mouse-selection copy keeps working, and Chromium's internal cache makes browser-to-browser copy look fine.

Recovery requires a logout/reboot. pkill -x wl-copy does not help. Installing xclip does not help either — Claude Code still picks wl-copy whenever WAYLAND_DISPLAY is set, despite referencing xclip/xsel in the bundle.

Reproducible: reboot → clipboard fine → /copy → broken.

Env: Fedora 44, GNOME 50 / mutter 50.3-2.fc44, wl-clipboard 2.2.1, Claude Code 2.1.212.

The requested OSC 52 preference would fix this, and an xclip/xsel fallback would too.

Follow-up: I verified that the OSC 52 path requested in this issue actually works, and that it also fixes the severe GNOME 50 breakage I described above.

Workaround: a PATH shim shadowing wl-copy that emits OSC 52 to /dev/tty instead of talking Wayland:

#!/bin/bash
# ~/.local/bin/wl-copy — shadows /usr/bin/wl-copy
sel=clipboard; osc=c
[ "$1" = "--primary" ] && { sel=primary; osc=p; }
payload=$(mktemp); trap 'rm -f "$payload"' EXIT; cat > "$payload"
if [ "$(wc -c < "$payload")" -le 74994 ] && { exec 3<>/dev/tty; } 2>/dev/null; then
  printf '\033]52;%s;%s\a' "$osc" "$(base64 -w0 < "$payload")" >&3; exit 0
fi
exec xclip -selection "$sel" -i < "$payload"   # fallback when there is no tty

Result on Zed's terminal: /copy lands 1800 characters byte-identical to the response.md it also writes, the selection is owned by the terminal emulator (mime pid/<zed-pid>) exactly as if I had pressed Ctrl+Shift+C, no wl-copy process is spawned, no invisible toplevel is created, and the compositor never wedges. Copy/paste to every GUI app keeps working afterwards.

So the fix this issue asks for — prefer OSC 52 when the terminal supports it — is validated end-to-end, and on GNOME 50 it is the difference between a working clipboard and a dead one.

Two things that may help whoever picks this up:

1. Installing xclip is not a workaround. The detection is effectively if (WAYLAND_DISPLAY && which("wl-copy")) use wl-copy, so wl-copy wins unconditionally on Wayland even when xclip/xsel are present and referenced in the bundle. There is no setting to override it.
2. A --primary call is issued alongside the clipboard one, so both selections are set; the shim above maps them to OSC 52 c and p.

Even short of preferring OSC 52 by default, an env var or setting to pick the backend (osc52 / xclip / wl-copy) would let affected users out. Happy to test a patch.

Env: Fedora 44, GNOME 50 / mutter 50.3-2.fc44, wl-clipboard 2.2.1, Claude Code 2.1.212, Zed 1.11.3.

I had a similar issue, running claude code in any terminal in intelliJ or rider - Selecting a section would produce a message saying that selection was auto-copied, however when i hit paste, it would be a different section, mostly happens when i need to scroll for longer messages.

THE FIX: Go to the global config of claude, in settings.json and remove {"tui": "fullscreen"} line

Hope this helps others

I had a similar issue, running claude code in a ssh terminal of Ubuntu. With or without rmux/tmux, Copy & Paster dose NOT work as expected.
It works fine bofore upgrade to version 2.1.220

This is a good feature, but it dose not worked anymore.