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

Environment: Claude Code 2.1.218, Linux Mint (Ubuntu 24.04 base), kernel 6.8.0-136, X11

Description

During normal Claude Code sessions, the CLI spawns xclip -selection clipboard and xclip -selection primary (likely for clipboard-sync on copy). These processes are left orphaned (PPID reparented to 1) with stdin attached to a live, never-closed Unix socket. They never exit, and hold the X PRIMARY/CLIPBOARD selection open indefinitely.

Effect

Any X client that queries/negotiates selection ownership blocks waiting on the unresponsive xclip, producing an intermittent full-desktop freeze — cursor becomes a crosshair, screen appears frozen, clears transiently on click, may recur several times before releasing. Reproduces across desktop environments (confirmed in both Cinnamon and Xfce) and even with the mouse physically disconnected, since it's an X-protocol-level stall, not an input-hardware issue.

Reproduction

Run several Claude Code shell commands in a session (e.g. repeated cargo build/clippy invocations); check ps aux | grep xclip — orphaned pairs accumulate over the session. Confirmed correlated with freeze reports 4/4 times by checking for live xclip processes at the moment of each freeze.

Workaround

pkill -9 xclip clears it instantly.

Suggested fix

Close xclip's stdin (or use a bounded write + explicit process wait/kill) after the clipboard write completes, rather than leaving the pipe open indefinitely.