Ctrl+Win key combination stopped working

Status Open
Reported on v2.1.222
Maintainer reply None cached
Activity 0 comments · opened Aug 5, 2026

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?

Still broken on v2.1.221/2.1.222 — additional detail: global hotkey never fires, not just paste

Reopening context on this: this regression is broader than "paste doesn't land." When focused in the Claude Code input (both the CLI and the desktop app), Wispr Flow's global activation hotkey (Ctrl+Win) doesn't fire at all — no dictation starts, no indicator appears. The same hotkey works reliably in every other application on the same machine (browser, Notepad, other Electron apps), so this isn't a Wispr-side config or permission issue.

This matches the mechanism in #37095 (Windows native Win+H voice typing failing with "select a text box and try again"): Claude Code's input control appears to no longer expose itself as a standard Windows text field / is intercepting keyboard input at a lower level than normal apps, which:

  • prevents Windows from recognizing it as a target for native voice typing (#37095)
  • prevents Wispr Flow's simulated paste from landing (this issue)
  • and, per my testing, prevents even the initial global hotkey from being seen by Wispr at all — a step earlier than the paste failure this issue describes

Environment:

  • Claude Code CLI: v2.1.221 (also present on v2.1.222)
  • Desktop app: Claude (MSIX/Store install), package Claude_1.25927.0.0_x64__pzs8sxrjxfjjc
  • OS: Windows 11 Pro, build 10.0.26200
  • Wispr Flow (current version)
  • Regression window: confirmed working pre-v2.1.83, broken from v2.1.83 onward, still broken as of v2.1.222 — no fix in the changelog between those versions

Given this affects Windows' own built-in voice typing (not just a third-party tool), could this get reconsidered rather than staying "not planned"? Happy to provide repro steps, logs, or a screen recording if useful.

---

Want any edits before you post it — e.g. trimmed down, or with your GitHub handle/session info swapped in?Here's a draft you can paste as a comment on [#38620](https://github.com/anthropics/claude-code/issues/38620) (or as a new issue if you'd rather keep it standalone):

---

Still broken on v2.1.221/2.1.222 — additional detail: global hotkey never fires, not just paste

Reopening context on this: this regression is broader than "paste doesn't land." When focused in the Claude Code input (both the CLI and the desktop app), Wispr Flow's global activation hotkey (Ctrl+Win) doesn't fire at all — no dictation starts, no indicator appears. The same hotkey works reliably in every other application on the same machine (browser, Notepad, other Electron apps), so this isn't a Wispr-side config or permission issue.

This matches the mechanism in #37095 (Windows native Win+H voice typing failing with "select a text box and try again"): Claude Code's input control appears to no longer expose itself as a standard Windows text field / is intercepting keyboard input at a lower level than normal apps, which:

  • prevents Windows from recognizing it as a target for native voice typing (#37095)
  • prevents Wispr Flow's simulated paste from landing (this issue)
  • and, per my testing, prevents even the initial global hotkey from being seen by Wispr at all — a step earlier than the paste failure this issue describes

Environment:

  • Claude Code CLI: v2.1.221 (also present on v2.1.222)
  • Desktop app: Claude (MSIX/Store install), package Claude_1.25927.0.0_x64__pzs8sxrjxfjjc
  • OS: Windows 11 Pro, build 10.0.26200
  • Wispr Flow (current version)
  • Regression window: confirmed working pre-v2.1.83, broken from v2.1.83 onward, still broken as of v2.1.222 — no fix in the changelog between those versions

Given this affects Windows' own built-in voice typing (not just a third-party tool), could this get reconsidered rather than staying "not planned"? Happy to provide repro steps, logs, or a screen recording if useful.

---

Want any edits before you post it — e.g. trimmed down, or with your GitHub handle/session info swapped in?

What Should Happen?

Claude should remove whatever is blocking the recognition of Ctrl-Win key combination

Error Messages/Logs

Steps to Reproduce

Put your cursor in the text box and press Ctrl-Win keys simultaneously

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.83

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗