Desktop app (Windows): hard crash right after the clipboard-change warning during dictation (Wispr Flow)

Summary

On the Windows desktop app the whole app crashes immediately after the clipboard safety toast appears:

Your app copied to the clipboard during Claude's interaction. If you didn't expect that, check it before pasting.

This is not the "toast is noisy / can't be turned off" problem already tracked in #90747, #87684, #89559 and #90980. Here the toast is followed by a hard crash of the desktop app: all windows close, and the Claude Code session running inside the app dies with it. It has happened repeatedly. Reinstalling the app did not help.

Environment

• Claude desktop app, MSIX package Claude_pzs8sxrjxfjjc, version 1.40609.1.0
• Windows 11 Pro 10.0.26200
• Claude Code running inside the desktop app — its processes are children of the desktop claude.exe, so they are killed by the crash
• Background clipboard writer: Wispr Flow voice dictation. It inserts text via Shift+Insert, i.e. it writes to the clipboard and restores the previous contents afterwards (shift-insert: true, disable-clipboard-restore: false in its config)
• Windows Clipboard History enabled
• Clipboard frequently holds image data (screenshots being pasted into the conversation)
• GPU: RTX 4090 (driver 32.0.15.9649) plus a Parsec virtual display adapter; hardware acceleration on

Pattern

1. A Claude interaction is running.
2. Another process writes to the clipboard — dictation inserting text, or a screenshot being copied.
3. The clipboard-change warning toast appears.
4. The desktop app crashes right afterwards.

Diagnostics

• No crash artifacts. Nothing in the Windows Application event log (Application Error / WER) at crash time, and no fresh Crashpad .dmp under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc. The newest WER entries are weeks old and belong to an older version. This is consistent with a renderer/GPU process crash that is caught internally rather than surfacing as a Windows crash report.

Suspected cause

A race when the clipboard is read for the warning while another process is concurrently writing to — or restoring — the clipboard. Most likely aggravated by image payloads and by several clipboard hooks being active at the same time (dictation tool + Windows Clipboard History).

Workarounds (not viable long term)

• Quitting Wispr Flow entirely
• Disabling Windows Clipboard History

Both defeat the point for anyone who relies on voice dictation while working in Claude — which is exactly the setup here.

Request

Guard the clipboard read behind that warning (retry / timeout / defensive handling of image formats) so that concurrent clipboard access cannot take the app down. An off switch for the toast, as requested in #89559 and #87684, would additionally side-step this crash path entirely.

Related

#90747, #87684, #89559, #90980 — same toast, but those report noise / missing off switch, not a crash.