Desktop app: clipboard-change warning toast has no off switch — constant false positives with dictation apps (Wispr Flow)
Environment
- Claude desktop app (macOS): 1.32352.1
- Claude Code: 2.1.220
- macOS: 26.5.2 (Darwin 25.5.0)
- Dictation tool: Wispr Flow
Problem
The desktop app shows this warning toast:
Your app copied to the clipboard during Claude's interaction. If you didn't expect that, check it before pasting. (×2)
I use Wispr Flow for voice dictation. By design it inserts text through the clipboard on every dictation: it writes the transcript to the clipboard, sends a paste keystroke, then restores the previous clipboard contents (documented at https://docs.wisprflow.ai/articles/6409258247-starting-your-first-dictation). That is two clipboard writes per dictation — hence the "(×2)".
So whenever I dictate while Claude is interacting with the Browser pane, the clipboard guard fires a false positive. Since dictating a follow-up message while Claude works is the normal flow, the toast appears after practically every dictation. The "Your app copied…" wording also misattributes the write to the previewed localhost app, which never touched the clipboard.
What I checked
- No setting in the app UI,
settings.jsonreference, or env var controls this toast. - The guard/toast path (
preview_clipboard_write_guard) appears to be unconditional apart from a 3-second rate limit — no config gate. - It is an in-app toast, not a macOS notification, so it can't be muted via System Settings.
- Wispr Flow has no clipboard-free insertion mode, so it can't be fixed from the dictation side.
Repro
- Open the desktop app with a Browser pane session (e.g. a localhost dev server preview).
- Ask Claude to do something that drives the Browser pane.
- While Claude is working, dictate anything with Wispr Flow into any app.
- The clipboard warning toast appears.
Expected / request
Any of these would solve it:
- A setting to disable the clipboard-change warning toast (keep the default on).
- Smarter attribution: ignore clipboard changes made by the frontmost/user-focused app while the user is actively typing/dictating, or recognize the write-then-restore-within-a-second pattern that clipboard-based text insertion tools (Wispr Flow, TextExpander, Raycast, Alfred, many IME/accessibility tools) all share.
- At minimum, a per-session "don't show again" on the toast.
The guard itself is a good idea — it just needs an escape hatch for users whose input method is clipboard-based.
3 Comments
Same on Windows 11, so this is not macOS-specific.
Voice dictation (Wispr Flow) into the Claude Code desktop app triggers the toast
on essentially every turn. Since dictation IS a clipboard write, the warning is
guaranteed to fire for the entire session.
The cost is that a security notice which fires every single turn stops being a
signal. You learn to dismiss it unread, which defeats its purpose: a genuinely
unexpected clipboard write would get clicked away out of habit.
A "don't show again" on the toast would be enough.
Hitting this too, and I want to add a data point that widens the scope: on my machine the toast fires on a plain, deliberate Cmd+C — no dictation tool involved at all.
Environment
Wording variant
The toast I get is phrased differently from the one in the original report, so there appear to be at least two variants of the same guard:
Why the manual-copy case matters
The original report frames this as a dictation false positive, which makes it look like a niche problem for Wispr Flow users. It isn't. Copying something while Claude is working is one of the most ordinary things a user does in this app — grabbing an error message, a file path, or a snippet to paste into the next prompt. Every one of those raises the warning.
That makes the false-positive rate structurally high for everyone, not just people using clipboard-based input tools. And the copy in question is one the user physically performed seconds earlier, so the warning is asking them to double-check an action they just took by hand.
The consequence is the one @leelaster already named: a security notice that fires on routine, self-initiated actions stops being read. I now dismiss it reflexively, which is exactly the state where a real clipboard hijack would slip past unnoticed.
Also worth noting for the dictation angle: this machine runs Aqua Voice, not Wispr Flow, so whatever the fix ends up being shouldn't be scoped to one vendor's insertion pattern.
Confirming there's no escape hatch
I checked before commenting: nothing in the settings reference, the desktop app docs,
settings.json, or the notification settings (agentPushNotifEnabled,inputNeededNotifEnabled,preferredNotifChannel) controls this toast. It's an in-app toast rather than a macOS notification, so System Settings can't mute it either. As far as I can tell there is currently no way to turn it off.Request
Seconding option 1 and option 3 from the original report — a setting to disable the toast (default on), or at minimum a "don't show again" on the toast itself.
One additional suggestion for the attribution problem: a clipboard write that happens while the app itself is frontmost and the user has recently pressed Cmd+C is almost certainly the user's own copy, and could be excluded without weakening the guard against the actual threat — a background write the user never initiated.
Confirming the same behavior on macOS (Darwin 25.5.0) with Wispr Flow — the toast fires with "(×2)" on every dictation made while a session is driving the Browser pane, matching the write-then-restore pattern described above. A mute setting or recognition of the write/restore pattern from clipboard-based input tools would resolve it.