Image paste on Wayland silently pastes text instead of the image when xclip is installed

Summary

On a Wayland session with xclip installed, pasting an image with ctrl+v silently
produces a small text file instead of the image. No error is shown — the paste
simply appears not to work. Uninstalling xclip fixes it completely.

Root cause is xclip, not Claude Code, but Claude Code is affected because its
clipboard fallback appears to try xclip before wl-paste and to accept the result
based on exit status.

Environment

• Claude Code 2.1.237
• CachyOS, kernel 7.1.8, KDE Plasma, Wayland session
• foot 1.27.0, wl-clipboard 2.3.0, xclip 0.13

User-visible repro

1. Wayland/KDE session, both wl-clipboard and xclip installed.
2. Take a screenshot in Spectacle, copy it to the clipboard.
3. wl-paste -l confirms image/png is offered.
4. Press ctrl+v in Claude Code → the image does not attach.
5. pacman -R xclip, repeat → works, full-resolution image attaches.

Root cause

On Wayland, KWin's Xwayland bridge mirrors only text to the X11 selection. When
xclip is asked for an image target it does not have, it does not fail — it returns
the stale X11 text selection and exits 0:

# put a known-good PNG on the Wayland clipboard
wl-copy --type image/png < known.png
wl-paste -l | head -1
# image/png

xclip -selection clipboard -t image/png -o > out.png; echo "exit=$?"
# exit=0
file out.png
# out.png: ASCII text, with no line terminators
head -c 120 out.png
# Whether Ollama/llama.cpp can do speculative decoding at all   <-- unrelated stale text

wl-paste --type image/png > out2.png; echo "exit=$?"
# exit=0
file out2.png
# out2.png: PNG image data, 4 x 4, 8-bit/color RGB, non-interlaced
cmp out2.png known.png && echo identical
# identical

So any xclip … || wl-paste … style fallback that branches on exit status will accept
xclip's bogus output and never reach wl-paste. The bytes written are not a truncated
or corrupt image — they are unrelated text from an earlier copy.

Detection and retrieval also disagree: something is clearly detecting the image
correctly (an image/png offer is present and visible to wl-paste -l), while
retrieval returns text. That mismatch is why the failure is silent.

Impact

Affects any Wayland user who has xclip installed — a common transitive dependency,
and one that is easy to have without knowing. The failure mode looks like a terminal
or compositor problem, so it costs a long diagnosis.

Suggested fix

Validate the content, not the exit status: after each branch, check the output is
non-empty and begins with the expected magic bytes (\x89PNG, BM, …) before
accepting it. Alternatively, prefer wl-paste ahead of xclip whenever
WAYLAND_DISPLAY is set.