# 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.