<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/linux-zoom-client-proactively-reads-x11-clipboard-fjvd2q2ai" -->

---
title: Linux Zoom Client Proactively Reads X11 Clipboard
description: A Linux user discovered that updating Zoom&#x27;s Linux client from version 6.6 to 7.1.5 caused it to start proactively reading everything written to the X11...
canonical: https://daily.dev/posts/linux-zoom-client-proactively-reads-x11-clipboard-fjvd2q2ai
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Linux Zoom Client Proactively Reads X11 Clipboard | daily.dev
og:description: A Linux user discovered that updating Zoom&#x27;s Linux client from version 6.6 to 7.1.5 caused it to start proactively reading everything written to the X11...
og:url: https://daily.dev/posts/linux-zoom-client-proactively-reads-x11-clipboard-fjvd2q2ai
og:image: https://api.daily.dev/og/posts/fJvd2q2Ai.png
og:image:alt: Linux Zoom Client Proactively Reads X11 Clipboard
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Linux Zoom Client Proactively Reads X11 Clipboard

**[Lobsters](https://daily.dev/sources/lobsters)** · 17 min read · 0 upvotes · 0 comments

## Summary

A Linux user discovered that updating Zoom's Linux client from version 6.6 to 7.1.5 caused it to start proactively reading everything written to the X11 CLIPBOARD selection (not PRIMARY), effectively snooping on any password manager that uses clipboard-based paste. He found this using a 'one-shot paste' tool (like xclip) that terminates after fulfilling one paste request - it immediately died because Zoom was requesting a paste as soon as it took clipboard ownership. The discussion, which drew hundreds of replies, notes a similar incident with Slack a year earlier, Zoom's history of other invasive background behavior (a local web server, background compiler processes, routing US calls through China), and a long tangent on whether Wayland's focus-gated clipboard access model would prevent this class of snooping, with commenters divided on whether Wayland actually fixes the underlying problem or just shifts the tradeoffs for tools like autotype and command-line clipboard utilities.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://hachyderm.io/@simontatham/117201594980991062>

## Questions this post answers

### Why does my one-shot paste tool immediately terminate after updating Zoom on Linux?

Zoom's Linux client version 7.1.5 (previously not the case in 6.6) proactively sends a paste request to the clipboard owner every time the X11 CLIPBOARD selection changes ownership, detected via the XFIXES extension. A one-shot paste tool fulfills the first paste request it receives and exits, so it terminates immediately because Zoom claims that request before the intended application does.

_daily.dev surfaces reports like this so developers relying on clipboard-based workflows can spot risky tool updates early._

### Does Zoom's clipboard reading behavior affect the CLIPBOARD selection or the PRIMARY selection in X11?

It only targets the CLIPBOARD selection, the Windows-style clipboard typically filled with Ctrl+C and read with Ctrl+V, and also XA_CLIPBOARD; it does not touch PRIMARY, the traditional X11 select-then-middle-click selection, or XA_SECONDARY. This matters because many password managers use CLIPBOARD to move a password into a target field, making them the ones exposed.

_track clipboard security nuances like this on daily.dev before trusting a password manager's paste mechanism._

### Does Wayland prevent applications from reading the clipboard in the background the way X11 allows?

On Wayland, generally only the application with keyboard focus can access the clipboard, which would stop a background app like Zoom from grabbing clipboard content while it isn't focused. However, this tradeoff also breaks command-line paste tools such as xclip run non-interactively, and any app can still fall back to running under X11 (via XWayland) to bypass the restriction entirely, so it isn't a complete fix.

_developers weighing an X11-to-Wayland migration can follow tradeoffs like these on daily.dev before switching._

## Community take

How the wider developer community reacted, aggregated from 2 discussions and 32 comments across lobsters, hackernews (as of 2026-09-13).

**TL;DR:** Commenters largely see this as another data point in Zoom's pattern of invasive background behavior on Linux, sparking debate over whether to use the desktop client at all and a long technical tangent on whether Wayland actually prevents this kind of clipboard snooping.

**Sentiment:** 0% positive · 25% mixed · 75% skeptical

**The pushback**

- Zoom appears to lack a way to disable clipboard reading, unlike Slack's earlier similar behavior which had an opt-out.
- Some argue the desktop client's other invasive history (background processes, telemetry) makes this unsurprising and a reason to avoid it entirely.
- The web client is seen by some as a safer alternative since browsers sandbox clipboard access more tightly.

**By community**

- lobsters (mixed): Split between recommending avoidance of the desktop client and defending it for features like screen sharing, plus a long technical debate on whether Wayland or better OS-level access control would actually prevent this.
- hackernews (mixed): No comments were provided for this discussion, so no take can be drawn.

**Hottest debate:** Whether Wayland's focus-gated clipboard model genuinely prevents this kind of snooping or merely shifts the same underlying tradeoffs elsewhere.

**Open questions**

- Does the Zoom web client exhibit the same clipboard-reading behavior as the desktop client?
- What exactly happens when Zoom runs under XWayland inside a Wayland session with respect to clipboard access?
- Could a portal-style permission system for clipboard access work in practice given how many legitimate use cases (menus, macros, image previews) rely on unrestricted access?

**Highlights**

> The poster says: > Regular readers might recall that around this time _last_ year I caught Slack doing something similar, but only when focus entered the Slack window, and also, they had a configuration option to turn it off This suggests that Zoom does not have an option to turn it off. This would mean that Zoom is always reading the clipboard, not only when "remote control" is turned on.
> — [tomsmeding on lobsters · 2 points](https://lobste.rs/s/8t1ddm/linux_zoom_client_proactively_reads_x11#c_7zpkxg)

> I know Wayland is at least different, though I have neither tested zoom there nor understand exactly how the clipboard functions. My assumption is zoom under xwayland will behave respective to other xwayland apps the same as it does on normal X11. It’s my understanding that the main difference is on X11 any running app can just read anything on the clipboard whenever it wants, whereas on wayland only the focused app can see the clipboard. If there are further restrictions that that I’m unaware of them
> — [darleaf on lobsters · 2 points, 3 comments](https://lobste.rs/s/8t1ddm/linux_zoom_client_proactively_reads_x11#c_rnxco1)

> Yes, exactly, there are tricky and interesting questions to ask here. And the Linux desktop ecosystem isn't even really equipped to answer them yet. Because the norm has been that every application does everything by itself. Want to take a screenshot? Just go ahead, the buffer is right there. Want to show file picker dialog? Just run some library code that draws the entire thing itself. This is very convenient for such a heterogeneous community but also it has historically meant that apps are styled very inconsistently and that everything runs at full user privileges.  The best thing I think we have that's trying to move beyond that is XDG desktop portal. I already run a sandboxed Firefox that does not have permission to read my entire ~ (and therefore my ~/.ssh/id_ed25519`) but that nonetheless allows me to upload arbitrary files from ~ upon my explicit permission (by selecting them in the file picker dialog that is *not* directly controlled by the Firefox process). Clipboard and Screenshots similarly work via portals. Most apps aren't able to work with this yet but the proportion is going up.
> — [muvlon on lobsters · 1 points](https://lobste.rs/s/8t1ddm/linux_zoom_client_proactively_reads_x11#c_9nqiie)

> The fact that Linux has horrible OS level control over what processes have access to the clipboard is dumb as hell.
> — [animatronic on lobsters · 2 points, 1 comments](https://lobste.rs/s/8t1ddm/linux_zoom_client_proactively_reads_x11#c_dilppt)

> 1) Isn’t it better to not need the full ingress/egress firewall in the first place, by virtue of browser sandboxing? A web app can talk to the world but it can’t talk to your computer or your clipboard. 2) what’s there to block when the attack is 1st party? zoom can just send this telemetry to the same ip you allowed in little snitch or whatever
> — [altano on lobsters · 1 points](https://lobste.rs/s/8t1ddm/linux_zoom_client_proactively_reads_x11#c_bvbgaj)

**Source threads**

- [lobsters](https://lobste.rs/s/8t1ddm/linux_zoom_client_proactively_reads_x11) · 50 points · 32 comments
- [hackernews](https://news.ycombinator.com/item?id=49537640) · 4 points · 0 comments

## Similar posts on daily.dev

- [ClipXDaemon: Autonomous X11 Clipboard Hijacker Delivered via Bincrypter-Based Loader](https://daily.dev/posts/clipxdaemon-autonomous-x11-clipboard-hijacker-delivered-via-bincrypter-based-loader-b6zi7n79n) · Cyble · 0 upvotes · 0 comments

---

Tags: [#linux](https://daily.dev/tags/linux), [#zoom](https://daily.dev/tags/zoom)

[View this post on daily.dev](https://daily.dev/posts/linux-zoom-client-proactively-reads-x11-clipboard-fjvd2q2ai)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Linux Zoom Client Proactively Reads X11 Clipboard","url":"https://daily.dev/posts/linux-zoom-client-proactively-reads-x11-clipboard-fjvd2q2ai","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/linux-zoom-client-proactively-reads-x11-clipboard-fjvd2q2ai"},"datePublished":"2026-09-12T17:48:40.054Z","dateModified":"2026-09-13T09:50:17.396Z","description":"A Linux user discovered that updating Zoom's Linux client from version 6.6 to 7.1.5 caused it to start proactively reading everything written to the X11...","image":"https://media.daily.dev/image/upload/s--CxzD6vbw--/f_auto/v1722860399/public/Placeholder%2005","thumbnailUrl":"https://media.daily.dev/image/upload/s--CxzD6vbw--/f_auto/v1722860399/public/Placeholder%2005","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/linux-zoom-client-proactively-reads-x11-clipboard-fjvd2q2ai","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"linux,zoom","timeRequired":"PT17M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Linux Zoom Client Proactively Reads X11 Clipboard"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/linux-zoom-client-proactively-reads-x11-clipboard-fjvd2q2ai#faq","mainEntity":[{"@type":"Question","name":"Why does my one-shot paste tool immediately terminate after updating Zoom on Linux?","acceptedAnswer":{"@type":"Answer","text":"Zoom's Linux client version 7.1.5 (previously not the case in 6.6) proactively sends a paste request to the clipboard owner every time the X11 CLIPBOARD selection changes ownership, detected via the XFIXES extension. A one-shot paste tool fulfills the first paste request it receives and exits, so it terminates immediately because Zoom claims that request before the intended application does. daily.dev surfaces reports like this so developers relying on clipboard-based workflows can spot risky tool updates early."}},{"@type":"Question","name":"Does Zoom's clipboard reading behavior affect the CLIPBOARD selection or the PRIMARY selection in X11?","acceptedAnswer":{"@type":"Answer","text":"It only targets the CLIPBOARD selection, the Windows-style clipboard typically filled with Ctrl+C and read with Ctrl+V, and also XA_CLIPBOARD; it does not touch PRIMARY, the traditional X11 select-then-middle-click selection, or XA_SECONDARY. This matters because many password managers use CLIPBOARD to move a password into a target field, making them the ones exposed. track clipboard security nuances like this on daily.dev before trusting a password manager's paste mechanism."}},{"@type":"Question","name":"Does Wayland prevent applications from reading the clipboard in the background the way X11 allows?","acceptedAnswer":{"@type":"Answer","text":"On Wayland, generally only the application with keyboard focus can access the clipboard, which would stop a background app like Zoom from grabbing clipboard content while it isn't focused. However, this tradeoff also breaks command-line paste tools such as xclip run non-interactively, and any app can still fall back to running under X11 (via XWayland) to bypass the restriction entirely, so it isn't a complete fix. developers weighing an X11-to-Wayland migration can follow tradeoffs like these on daily.dev before switching."}}]}
```

