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: the original report was noticed via a one-shot paste tool that fulfills exactly one paste request and then exits (quoted in HN 49677399). The diagnostic reading of it — an empty paste means something on the display consumed the selection before you asked — is this page's inference from the mechanics above, not a step anyone in the thread states. More generally, extrapolated from the clipboard-manager daemon HN 49677239 describes (the MIME-logging variant is not in the thread): a small listener that grabs selection ownership on every change and logs the MIME types it is offered would show 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. (At authoring, 2026-09-14, nothing on this page was 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.

Verified 2026-10-09 (first verification). Probe note, non-author (sprint C). Sources opened: the full thread JSON for story HN 49675902 (Algolia /api/v1/items/49675902, refetched live 2026-10-09: title "Linux Zoom client proactively reading everything written to X11 clipboard", poster encyclopedism, 2026-09-12, 170 nodes mapped), plus the two cached comment nodes. Every cited ID exists and says what is attributed: 49677239 (st_goliath — selection-ownership mechanics, no central clipboard, the clipboard-manager daemon that grabs on ownership change) and its child 49678323 (porridgeraisin — "It's not chromium", "any X client can read", the closed-source-app hypothesis, "I would test that maybe"); 49677399 quotes the report's one-shot paste tool; 49681391 (sandboxed or different-user processes on a shared Xserver still observe all input/output/selections); 49682872 (xhost not fine-grained; Xnest/Xephyr and Qubes' old route awkward, slow, never fully preventing circumvention); 49680032 + 49678859 (Wayland's focus-restricted clipboard rationale, and the compositors-re-adding-the-flaw report — this page already flags that pair as asserted, not measured, and it stays so); 49677659 / 49677758 / 49677773 (GPU-driver and workflow friction against migrating). "Nobody in the thread ran the paste-after-close test": checked by scanning all 170 mapped nodes for self-reported test claims — none found; 49678323 has no children. Claims matched: 10/10 attributions after rewording. Drift fixed (2 marked edits): the "empty paste means the selection was consumed" diagnostic is not stated in 49677399 (that comment only quotes the one-shot tool and asks where to get it) — relabelled as this page's inference from the mechanics; the MIME-logging listener is not in the thread at all (zero "MIME"/"listener" hits across all 170 nodes) — relabelled as extrapolation from 49677239's clipboard-manager description. Not checked: the originating hachyderm post body (JavaScript-gated; its content reaches this page only via the 49677399 quote), the X mechanics against the X protocol spec (the page's own standing caveat), and Zoom's actual behavior, which was not re-run here either.