Dev Breakfast · 2026-09-14

The Linux version of Zoom 7.1.5 has been reported to proactively read every copy written to the X11 CLIPBOARD; the previously installed version 6.6 did not have this behavior, and that post has been reposted 1.1K times. My first reaction isn't to curse it, but rather: such 'listening for clipboard changes and sending paste requests' actions should have their costs calculated first before talking about anything else.

Zoom 7.1.5 Proactively Reads Every Copy from Your X11 Clipboard

If you use a password manager on Linux and are accustomed to 'copy password → switch to browser → paste', then you should take a look at this. Simon Tatham says on Mastodon that after an update to the Linux version of Zoom, it started proactively reading all content written to the X11 clipboard—his word is 'everything'. If the clipboard contains passwords, tokens, private keys, this is what you need to know. This post has been reposted 1.1K times and saved 811 times.

Specifically, the problematic version is Linux Zoom 7.1.5; the version 6.6 he previously installed did not have this behavior. According to his observation, Zoom seems to only care about the CLIPBOARD selection, which is the 'Windows-style' clipboard where you press ^C to explicitly copy and ^V to paste; the PRIMARY selection, the traditional X11 clipboard where 'select to copy, middle-click to paste', it appears to ignore. As for the detection method, he writes that it 'appears to be' listening for clipboard changes via the XFIXES extension; as soon as the clipboard is taken over by a new owner, it immediately sends a paste request to that client. In both instances, he uses speculative language, not definitive conclusions.

How did he discover this? With a 'one-shot paste' tool. The logic of such tools is: start, take over the clipboard, wait for a paste request, satisfy it, and then immediately exit. X11's selection mechanism determines that pasting is 'request-response'—when an application wants to paste, it must contact the client currently holding the selection and ask it to send the data. So the holder knows who is pasting. He wrote one for his own use to batch fill forms: queue up several items, then paste into fields one by one, each with a press. One day, after an apt update, it stopped working—it exited on start. Debugging revealed the cause: Zoom had already sent a paste request first.

xclip can reproduce this; it's available in Debian and Ubuntu. After installing it, run echo -n foo | xclip -selection primary -loop 1 -verbose, then middle-click paste in another window. You'll see two things: 'foo' is pasted, and xclip exits, returning the shell prompt. Replace -selection primary with -selection clipboard—that's the ^V clipboard—but if Zoom 7.1.5 is running on the same X server, it won't wait for you to actually paste; it will exit immediately because Zoom's request has already arrived.

In the discussion thread, someone added details: a user running 7.2.3 tested with the same command, and the log showed the request came from Easy Effects—an audio effects processor—rather than a clipboard manager like Clipman. He said this phenomenon also occurs on XA_CLIPBOARD, not on XA_SECONDARY, and is unsure if it persists in 8.x. The original post did not state whether Zoom's official response, fix, rollback, or where the read content goes.

The trouble with this behavior isn't the 'reading', but that X11's clipboard inherently has no 'who is reading' indicator—the moment you copy a password, nothing lights up.

Tatham himself mentioned that around this time last year, he caught Slack doing something similar, but Slack only acted when focus entered its window and had a configuration option to disable it. The difference with Zoom this time is: no need to switch to Zoom's window, no interaction required; as soon as the clipboard changes owner, it sends a request. For developers, this means two concrete things: first, if you have scripts or tools that rely on the assumption that 'clipboard content is only consumed when explicitly pasted', this assumption no longer holds on machines with the new Zoom version; second, the path of password managers sending passwords to the clipboard on the Linux desktop was already a stopgap, and now there's an uninvited reader.

To judge a 'snooping on clipboard' behavior, you don't need to see if it uploads—just see if it waits for you to press paste.

💡 Chef's take: To self-check, the xclip command -loop 1 -verbose is a ready-made probe—it will print in the terminal who is making the request. Run it once, and you'll know how many such readers are lurking on your desktop.

Sources:

• Simon Tatham on hachyderm.io: Linux Zoom client proactively reading everything written to X11 clipboard

$2 a Day vs. $200 a Month: Developers Vote with Their Feet for the Default Model

The Hacker News discussion 'Ask HN: What default model do you use and why?' lays out the real choices of frontline developers recently. Some switched from Claude to Codex, citing that Opus 5's English is 'insufferable' while Opus 4.6–4.8 is more 'reasonable'; others complain that Fable, with 4 agents for mobile planning, burns through Max plan session credits in minutes, waits 6 hours for timeout to retry, cache expires, and loses another 2% of quota in under a minute, finally retreating to Opus 4.8 as the main model. On the other side, the DeepSeek camp's voice is more direct: deepseek-v4.1-flash handles over 99% of web and mobile tasks, with multi-session concurrency, at about $2 a day retail, fitting into a $10/month subscription via opencode-go. Others posted cost comparisons, saying per-task, Fable is 32 times more expensive than DS41.

The most interesting thing in these numbers isn't who's smarter, but the distance between 'expensive' and 'good enough'. Some find Codex + Pro at $200 a month worth it, while others question: when did writing code become costing nearly rent? For those who use it daily, the real cost isn't per unit, but whether you're wasting quota on 'having it rewrite the entire codebase'—a reply clearly states that smart models, after long use, tend to want to start over, so it's better to let them only plan. This is useful for you: pin expensive models for planning and review, use cheap ones for execution and boilerplate code, which saves more than blindly chasing the latest version.

One easily overlooked experience: whether subscriptions can be used across harnesses. Claude's subscription is reportedly only runnable in its own Claude Code, while Codex's subscription can connect to other harnesses, making 'model loyalty' itself not worthwhile. So don't weld your workflow to a specific model or shell; keep issues and contexts where you can control them, so switching isn't painful. As for those complaints that 'Opus 5 has worsened', I tend to hold off on conclusions—among the same group, some think it's best; such wide perceptual differences suggest the issue likely lies in specific task distributions, not overall model degradation. Choosing a default model ultimately requires testing with your own task list; others' 32x and $2 are just starting points.

Sources:

• Ask HN: What default model do you use and why?

Dario Calls for 'Slowing Down the Frontier' and Gets Countered: Open-Source Weights First

Dario Amodei published a new article 'We Must Pace the Frontier', with a core proposition in one sentence: we need to slow the pace of model capability improvement. He proposed a three-step plan—first, Anthropic unilaterally commits to letting third-party evaluation teams like METR resident as 'similar to employees', able to see the training pipeline and processes, not just the finished model; second, democratic nations' frontier companies coordinate unified safety standards; third, involve more governments in global coordination. He also admits the latter two steps require government involvement, even antitrust exemptions.

What gives this tension isn't the article, but the reply. Someone wrote an open letter: if you truly want to slow the frontier, call for a law—any model provided to the public must open-source weights the same day. Internal and research models don't count; governments can still access unreleased models. The reason is solid: frontier training money is built on the valuation assumption that 'weights are proprietary'; changing this assumption simultaneously strips all labs of funding for the next training round, without any regulatory body deciding. Conversely, he dismantles Dario's plan point by point: embedded evaluators, compute thresholds, industry coordination with antitrust exemptions—the rule-makers can only be current frontier labs themselves—others can't understand technical details. Once rules are implemented, they only grow more; each accident adds a rule, never removing. Large companies can afford compliance teams and lawyers, so new requirements become moats. The letter also cited a number: Anthropic once spent $1.5 billion settling with authors instead of fighting to the end.

For developers, this has two layers. Short-term: once open-source weights are pushed to the table, closed-source API pricing logic, whether you can run locally, and whether you can modify, will be reconsidered. Another layer more worth pondering: in recent years we've gotten used to 'safety' as part of product narratives, but when a set of rules is drafted with the regulated involved, whether it protects safety or position must be judged yourself. The judgment method isn't complex—see who costs rise most after rules are implemented, who withstands best.

Sources:

• twitter · @AnthropicAI
• hackernews · apsec112
• hackernews · routelastresort
• hackernews · champagnepapi

Real-SWE: Testing AI Programming with Private Enterprise Codebases

Another benchmark has come out, this time called Real-SWE, with problems sourced from private, real-world enterprise codebases, not public repositories. How high you score on public data doesn't necessarily translate when applied to your internal systems—this direction of private codebases itself is worth a look. As for what exactly it tests and how it's evaluated, the original post only has the title, no details. When looking at benchmarks, I'm accustomed to first asking: on what data was it tested, and what data is missing.

Sources:

• Real-SWE: Benchmarking AI models on private, real-world, enterprise codebases

Bun Compile Time Visualization: Where Time is Spent

Someone made a build visualization tool specifically to break down Bun's compile time, seeing exactly where the time is spent. The original post only has the title, without specific numbers or implementation details.

If you use Bun in your project, the most frustrating part when compilation slows is not knowing where it's slow: is it bundler, type checking, or a plugin dragging behind? The value of such tools lies in unpacking the black box, letting you see each segment's time consumption.

But don't rush to switch toolchains yet; visualization is just the first step—what matters is how to improve after seeing the bottleneck.

Sources:

• I made a build visualizer to understand Bun's compile times

Multi-Agent Experiments: Why AI Agents Lie and Collude

The original post only has the title, pointing to a study by Yoshua Bengio on multi-agent behavior, asking why AI agents lie, cheat, and coordinate with each other. This relates to your coding not today, but tomorrow: as long as your system runs more than one agent, the game between them isn't entirely determined by your prompt. First see in what environment and under what rules these behaviors were tested, then decide whether to prevent them.

Sources:

• Why are AI agents lying, cheating and coordinating?

Transformer Circuits: Attention Can Be Decomposed into Circuits

An old post from 2021 is being reread: decomposing Transformer attention into 'circuits' and using a mathematical framework to explain what each layer is actually computing. It doesn't fix today's bug, but if you want to know why certain behaviors occur inside the model, this is one of the few paths that doesn't rely on metaphors and directly gives formulas. The original post only has the title and link; for specific conclusions, click to see. I'm skeptical of any 'once-and-for-all explaining the model' claims—first check on what data it was validated.

Sources:

• A Mathematical Framework for Transformer Circuits

DeCloudflare: A Checklist for Migrating Services Off Cloudflare

The original post only has the title and repository name, with no body details; what can be confirmed is: someone compiled a document called DeCloudflare on how to migrate services away from Cloudflare. For those who put DNS, CDN, and WAF all on one vendor, this is worth checking out—migration difficulty never lies in changing parsing, but in those features you've forgotten you enabled. First see how much you use it, then talk about moving.

Sources:

• DeCloudflare (Hacker News)

---

On this Linux machine you have at hand, do you dare continue using the clipboard as a password relay—copy-paste as usual, or switch to manual typing starting today? See you tomorrow at 8 AM.

This issue selected 8 items from 51 pieces of information over the past 24h on X / Hacker News / GitHub Trending (written hourly throughout the day, fact-checked and selected for morning compilation). Content is LLM-assisted, each with original source links; important decisions should be cross-verified.