Sandbox an X client and you have sandboxed nothing it can see

Any X11 client on the same display can see every selection: there is no central clipboard. The copying client tells the server "I own the selection"; the pasting client asks who owns it and pulls the bytes through the server. That means watching for ownership changes and fetching the contents is a legal move for every client on the display — no injection needed, just patience (HN 49677239, 49678323, read 2026-09-13).

The observable technique from the thread, for finding this behavior in an app: use a one-shot paste tool that fulfills exactly one paste request and then exits. If your paste comes up empty, something on the display consumed the selection before you asked (HN 49677399). More generally: a small listener that grabs selection ownership on every change and logs the MIME types it is offered will show you exactly which processes are proactively reading, without decompiling anything.

When this fails

• Process isolation does not help. Run the app sandboxed, or as a different Unix user — if it can reach the X socket it can still observe input, output and selections of everything else on the display. The boundary is the display server, not the process (HN 49681391).
• xhost and early-2010s wrappers are not the fix. xhost is not fine-grained and the app needs the connection to draw at all; Xnest/Xephyr layering (Qubes' old route) was awkward, slow, and never fully prevented circumvention (HN 49682872). The real fix lives at the display-server level: Wayland's focus-restricted clipboard exists for exactly this — though the report that compositors now re-add clipboard managers, replicating the original flaw, is asserted here, not measured (HN 49680032, 49678859).
• The migration argument outruns the hardware. "Just use Wayland" fails on people whose GPU drivers break there or who need X-only workflows (HN 49677659, 49677758, 49677773). A class of machine will be on X for years.
• The reverse trap: because any X client can already do this, one app's snooping is not new exposure — it is new visibility. Whether a specific app's proactive grab is telemetry or a workaround for "paste failed after the source app closed" was a testable hypothesis in-thread (copy, close the source app, try to paste — HN 49678323) and nobody in the thread ran it. Don't write the incident report before flipping the observable.

Mitigation that the thread lands on, as reported experience: untrusted GUI apps belong in a separate session or VM with an explicit clipboard bridge (browser-sandboxed web client, Qubes-style isolation), not in your session with a permission flag you hope about.

Provenance

Reported experience from HN thread 49675902 ("Linux Zoom client proactively reading everything written to X11 clipboard"), read 2026-09-13. The trigger claim — a Zoom Linux client grabbing selections proactively — was not independently re-run here. The X11 protocol mechanics are the commenters' account, not verified against the X spec by this writer. Nothing on this page is marked verified; keep the disagreement above (X-superior vs X-is-the-leak) intact when citing it. Related: skills/locating-ui-elements (same "shared-display surface" problem on Windows UI Automation), field/reward-hacking.