[BUG] TUI copy-to-clipboard silently fails on Wayland (kitty) even though wl-copy is installed and working (2.1.201) — backend present, unlike #84184

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest is #84184, which covers the missing-backend case — this is the opposite: backend present and working)
• [x] This is a single bug report
• [ ] I am using the latest version of Claude Code (on 2.1.201 — see below; will retest on latest if asked)

What's Wrong?

Environment

• Claude Code 2.1.201
• Linux 6.18.37 x86_64 (Nix-based system), fish shell
• Terminal: kitty (TERM=xterm-kitty)
• Session: Wayland (WAYLAND_DISPLAY=wayland-1) — note DISPLAY=:0 is also set (XWayland)
• Clipboard utilities: wl-copy 0.9.3 present at ~/.nix-profile/bin/wl-copy and on PATH; xclip and xsel are not installed

What happens

Copying text out of the Claude Code TUI does not reach the system clipboard — pasting afterwards yields nothing / stale content. No error or warning is shown anywhere.

The clipboard stack itself is fine in the very same environment: running wl-copy < file from a Bash tool call inside the same Claude Code session put the content on the clipboard immediately and pasting worked. So this is not the missing-backend situation from #84184 / #67486 — the backend exists, is on PATH, and works when invoked directly.

Why this might be happening (untested hypothesis)

Given that:

• wl-copy is installed and functional,
• xclip/xsel are absent,
• both DISPLAY and WAYLAND_DISPLAY are set (standard on Wayland desktops with XWayland),

a backend-selection order that checks DISPLAY first and picks an X11 utility path would land on a missing xclip/xsel and fail — apparently silently, same failure symptom as #84184 but with the opposite root cause (backend present, wrong one chosen). The CHANGELOG entry for 2.1.161 ("clipboard now uses wl-copy/xclip/xsel on Linux when available") is where this selection logic appears to have been introduced.

kitty also supports OSC 52 writes out of the box, so an OSC 52 fallback would have worked here too.

Real-world impact

Same as #84184 describes: the failure is completely silent, so the user experiences it as "the clipboard feature is broken" with nothing to go on. Whatever the resolution, a visible error when a clipboard write fails (or when the chosen backend is missing) would turn a debugging session into a one-line fix.

Notes

• Exact UI action used for the failed copy (mouse drag-release auto-copy vs. keybinding) — happy to pin down and follow up with a precise repro if useful.
• Related: #84184 (missing-backend silent failure), #67486.