@glent ah, yes, now I see that in the web version of Settings it's there, a long way down a very large page.

But no luck, I'm afraid. I turned that off; pressed Save; quit and restarted the local Zoom client, since you said the web settings might only be loaded at startup; and alas, the unwanted clipboard slurping is still happening.

@glent that sounds like a very plausible thing to try, but I can't find that setting!

In the Zoom client's Settings dialog box, the "My account" entry in the left sidebar only offers me some links to the web version of my account settings, an option to make a voice recording for smart voice recognition, and a list of all the clients logged in to my account.

Other plausible sidebar entries, like "Meetings & webinars" or "Share screen", don't have any option of that kind either.

Searching for 'clipboard' in the whole settings box, via the search tool at the top of the left sidebar, only finds "Automatically copy invite link to clipboard" in the Meetings tab.

@shrub900 I see, thanks. So a side effect would be that command-line pasting tools, like 'xclip -o', also couldn't work?

That's quite a big tradeoff for some users – me in particular. I use that kind of workflow a lot. As and when I move towards Wayland, I'll have to work out what to do about losing that.

@shrub900 can you say how? I've never got round to learning Wayland. What restrictions can it place on clipboard use that prevent this kind of unwanted behaviour while still allowing intentional copy-paste?

@nicksilkey the way the X11 selection mechanism works is that every time an application wants to paste, it contacts the current selection owner and asks it to send the data.

This allows some amusing stunts, like writing a selection client that always pastes the _current_ time, rather than the time the clipboard was (logically speaking) written. But it also means that the selection-owning application _knows_ when someone is pasting from it, and can do things in response.

A one-shot paste tool is a thing that starts up, claims ownership of the clipboard, waits until it's received and fulfilled _one_ paste request, and then immediately terminates.

It so happens that I use one I wrote myself. But others exist. One that's already available in Debian and Ubuntu is 'xclip'. If you do this …

sudo apt install xclip # if you don't have it installed already
echo -n foo | xclip -selection primary -loop 1 -verbose

... then middle-clicking in some other window should cause two things to happen. First, it pastes 'foo'. But also, the xclip tool terminates, and your shell prompt comes back in the first terminal.

If you use '-selection clipboard' instead of '-selection primary' then it will write the other clipboard, the one that typically pastes using ^V or similar. Except that if you're running Zoom 7.1.5 on the same X server, it won't wait for you to paste something on purpose – it will terminate immediately, because it already received a paste request from Zoom!

@Brett_E_Carlock good point, I should have specified that. It's the .deb package.

Some details:

This is Linux Zoom 7.1.5. Previously I had 6.6 installed, which didn't do this.

It appears to only care about the CLIPBOARD selection – the one with Windows-ish UX, which you typically copy to explicitly with a keystroke such as ^C, and paste from with ^V (or similar). It doesn't look at PRIMARY, the selection used for trad X11 "just select in this window then middle-click in the other" copy-paste.

It looks as if it's detecting changes of clipboard via the XFIXES extension, and whenever the clipboard is claimed by a new owner, it immediately sends that client a paste request.

I noticed it because I make heavy use of a "one-shot paste" tool which fulfills a single paste request and then terminates. Handy for filling in lots of fields of a web form – queue up pastes of several different things, then go to each form field in turn and just hit paste, bam bam bam. But today, after an apt update, it doesn't work: my one-shot paste tool terminates as soon as it starts, because (I found out after some debugging) Zoom always requests a paste immediately.

(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. A one-shot paste tool seems to be a good way to notice weird things going on in the X server!)

I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard.

If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!