Image paste probe (xclip -t TARGETS -o) hangs forever on X11, leaving stuck processes for hours

Summary

On Linux/X11, the clipboard-image check runs

sh -c 'xclip -selection clipboard -t TARGETS -o 2>/dev/null | grep -E "image/(png|jpeg|jpg|gif|webp|bmp)" || ...'

xclip has no timeout. An X selection read blocks forever when the selection owner
does not answer the TARGETS conversion request, which happens whenever the owning
application is busy, wedged, or gone without releasing the selection. The probe then
never returns and the process stays alive indefinitely.

What I saw

Four of these processes alive at once on one machine, aged 21 hours, 8.9 hours,
4.9 hours and 4.9 hours. All were blocked in poll_schedule_timeout
(/proc/<pid>/wchan), each with its sh -c parent still attached. Killing them is
the only recovery; they never time out.

Version: Claude Code 2.1.280, X11, a Chromium-family browser as the copy source.

Why it matters

• A paste that triggers the probe can appear to do nothing.
• The stuck readers accumulate, one per attempt.
• On X11 the copying application must serve the data, so an unresponsive owner is

normal rather than exceptional, and a browser bug on the other side is enough to
cause it.

Expected

The probe should time out (a second is generous for a local selection read) and be
reaped, then fall back to treating the clipboard as text.

Suggested fix

Run the probe under a timeout, for example timeout 1 xclip ..., and kill the child
on expiry. wl-paste --list-types on Wayland deserves the same treatment.