[BUG] Windows: chat input + push-to-talk mic freeze when SuperWhisper (dictation app) is running

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, the Claude desktop app (Cowork mode) chat input intermittently becomes unfocusable mid-session — it won't accept clicks or keystrokes. At the same time, the app's built-in push-to-talk mic stops responding. Both recover reliably the moment I close SuperWhisper, a third-party dictation app running in the background.

Note: this is a Claude Desktop (Cowork) bug, not a Claude Code CLI bug. Filing here as the only available public channel, per precedent in #58536 and related reports.

This appears to be a DIFFERENT bug from the IndexedDB/backing-store freeze in #58536: in that report, only logout/login restores the input (consistent with a storage rebuild). In my case, simply closing SuperWhisper restores both the input and the mic instantly — too fast to be a storage rebuild — which points to an external-app input conflict rather than internal storage failure. Likely candidates: SuperWhisper's global keyboard hook (used for its activation hotkey) stalling and interfering with keyboard input system-wide, or clipboard contention from its text injection.

Frequency: intermittent. Doesn't happen every session, but when it does, closing SuperWhisper fixes it every time.

Observations:

• Both symptoms (dead text input + dead push-to-talk mic) appear together, not separately.
• The input box still renders normally; it just won't take focus or input.
• Restarting the chat alone does not reliably clear it; closing SuperWhisper does.

Environment:

• Claude desktop (Cowork mode), app version 1.15962.1.0
• Windows 11 Pro, 25H2 (build 26200)
• Third-party app involved: SuperWhisper 1.5.1

Filed in parallel with SuperWhisper support, since it's not clear from the outside which side owns the fix.

What Should Happen?

The chat input and built-in push-to-talk mic should stay functional regardless of other apps running in the background. If a third-party app holds the clipboard or a keyboard hook, the input editor should degrade gracefully rather than locking, and should recover on its own without requiring the other app to be closed.

Error Messages/Logs

No error messages surface in the UI — this is an input lock, not a crash. Happy to capture desktop logs (%APPDATA%\Claude\logs) from a freeze window if that would help isolate it.

Steps to Reproduce

1. Have SuperWhisper (Windows dictation app) running in the background.
2. Open the Claude desktop app (Cowork mode) and start or resume a chat.
3. Use the chat normally over several turns, including dictating into it with SuperWhisper and/or using the built-in push-to-talk mic.
4. Intermittently, the chat input stops accepting focus and keystrokes, and the built-in push-to-talk mic stops responding at the same time.
5. Close SuperWhisper — both the input and the mic recover immediately.

Note: this is intermittent, not every session, so I can't give a deterministic trigger. But the correlation is consistent: when it occurs, closing SuperWhisper is the reliable fix, and restarting the chat alone is not.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — this is the Claude Desktop app (Cowork mode), not the Claude Code CLI. Desktop app version: 1.15962.1.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Note: the "Platform" and "Terminal/Shell" fields above are Claude Code (CLI) specific and don't really apply here — this is the Claude Desktop app (Cowork), not the CLI. I selected the closest Windows-consistent values to avoid a macOS/Windows contradiction; no terminal or API platform is actually involved in this bug.

This report was filed in parallel with SuperWhisper support, since the conflict could be owned by either side. Happy to provide desktop logs from a freeze window if helpful.