Orphaned xclip processes leak an open X selection grab, causing intermittent desktop freeze (Linux)

Correction: further testing shows these orphaned xclip processes are present continuously in the background (spawned per Bash tool call) regardless of whether a freeze is occurring — this was a confound in my original correlation, not causal. The actual freeze cause is still unidentified. Apologies for the noise; leaving this open only as an FYI that Claude Code does leave xclip processes orphaned (which may be worth fixing on its own merits), but it is NOT the cause of the desktop freeze originally reported here.

Partially reproduced on 2.1.233 (Linux, X11).

After a single clipboard copy from the CLI, I can confirm two xclip processes are left behind (xclip -selection primary and xclip -selection clipboard), both reparented to PID 1 with stdin attached to a live, never-closed socket — exactly as described. They hold the PRIMARY and CLIPBOARD selections for the rest of the session (in my testing they did exit once the Claude Code process itself exited, and a subsequent copy replaced the previous pair rather than stacking, so accumulation likely comes from running several concurrent sessions — one lingering pair each).

I could not verify the desktop-freeze effect itself in a headless X server (no desktop environment / clipboard manager present to do the selection negotiation that stalls), so that part is unconfirmed but consistent with the leaked processes above.

One note: any X11 clipboard write needs some process to stay alive to serve the selection (that's how X selections work), so a lingering owner isn't entirely avoidable — but the open-stdin orphaned processes reported here are real and reproducible.

🤖 Generated with Claude Code

Another data point for the freeze link, with a reproducible mechanism on the xclip side.

Environment: Claude Code 2.1.283, "tui": "fullscreen" (copyOnSelect at its default), KDE Plasma 6.7.5 on X11, Alacritty, xclip 0.13 (Arch package, built from the 0.13 tag).

What happened: The panel clock froze, plasmashell stopped answering D-Bus, and Dolphin got the "not responding" dialog (stack: KFileItemClipboard::updateCutItems → QMimeData::data → QInternalMimeData::formats → QXcbClipboard wait). The PRIMARY owner at that moment was a daemonized xclip -selection primary spawned by Claude Code (reparented to systemd --user, stdin a socket). Killing that single process made plasmashell respond again immediately.

Why this takes down the whole desktop on KDE: Klipper runs inside plasmashell, reads PRIMARY on every change and owns CLIPBOARD itself. While plasmashell waits on an unresponsive PRIMARY owner (Qt waits 5 s per request, several requests per read), every other application that reads CLIPBOARD waits on plasmashell.

Mechanism in xclip 0.13 (reproduced on Xvfb with a Qt requestor):

• For selections of 1 MiB or more, xclip 0.13 uses INCR and serves one transfer at a time; requests arriving meanwhile are dropped (Qt waits 5 s).
• If a requestor abandons an INCR transfer, xclip 0.13 never answers again and ignores SelectionClear (astrand/xclip#34, open since 2017). Afterwards Qt formats() takes 5 s and text() 20 s, indefinitely.
• xclip master (2c3b811) fixes both, but distributions still ship 0.13. xsel 1.2.1 passes the same test.

I could not reproduce a hang with small selections, and the size of the copy that triggered it is unknown, so the xclip bug may not be the whole story.

Claude Code side:

1. xclip is spawned with stdout/stderr piped. xclip daemonizes and the child keeps those pipes, so every spawn runs into the 2 s timeout and the orphan stays attached (still true with xclip master, see astrand/xclip#11). Spawning the helper with stdout/stderr ignored avoids this; xsel closes its stdio on its own.
2. Every copy-on-select spawns two xclip owners (CLIPBOARD and PRIMARY) on top of the OSC 52 write (#96123), and an active selection is re-copied while output streams (#41954). That multiplies the selection churn clipboard managers such as Klipper react to.
3. Suggestions: spawn clipboard helpers with stdio ignored, prefer xsel over xclip when both are installed, and make taking PRIMARY opt-in.

Workaround: install xclip from git (e.g. xclip-git on the AUR).