claude-code - 💡(How to fix) Fix Title: Windows: Delegate push-to-talk to OS-native Voice Typing API for improved reliability and accuracy [2 comments, 2 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Claude Code's built-in speech-to-text on Windows has a pattern of persistent reliability issues. The audio capture module path is hardcoded to a CI build machine path, causing /voice to fail entirely (#30915). Third-party voice dictation tools like AquaVoice and Wispr Flow have broken compatibility across updates (#20570, #38620), and the push-to-talk spacebar input has regressed with keystrokes passing through to the terminal during recording (#38620).

Beyond these integration failures, the transcription quality itself is a concern — the built-in STT frequently drops words and intermittently fails to register input at all. Meanwhile, Windows natively provides a high-quality, battle-tested Voice Typing API (Win+H) that consistently outperforms the current implementation in both accuracy and reliability.

Proposed Solution

On Windows builds, delegate push-to-talk to the OS-native Voice Typing API rather than maintaining a custom audio capture, encoding, and transcription pipeline. The integration surface is minimal — a SendInput call to invoke Voice Typing on spacebar hold and another to dismiss it on release.

This approach would:

• Eliminate the entire Windows audio capture pipeline and the maintenance burden that comes with it
• Resolve the hardcoded path issue (#30915) by removing the dependency on audio-capture.node entirely
• Restore third-party tool compatibility (#20570, #38620) by removing the custom input interception layer
• Improve transcription accuracy by leveraging Microsoft's continuously updated speech model
• Support offline dictation without requiring network connectivity
• Leverage the user's trained voice profile for personalized recognition

Alternative Solutions

A ~30-line AutoHotkey v2 script can replicate this behavior today by unbinding Claude Code's voice:pushToTalk keybinding and remapping spacebar-hold to Win+H. This workaround is currently outperforming the shipped feature — which itself suggests the native API is the correct architectural choice. A similar pattern could be explored on macOS using the native Dictation API for cross-platform parity. Related issues: #30915, #20570, #38620, #34305, #16233

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

1. Extended coding sessions with voice input — A developer working through a multi-hour session uses push-to-talk to describe implementation requirements, explain bugs, and dictate commit messages. With the current STT, dropped words force them to re-dictate or manually correct transcription errors, breaking their flow. The native API transcribes accurately on the first attempt.
2. Technical vocabulary and code references — When dictating messages that include function names, library names, or technical jargon (e.g., "refactor the useEffect hook in the AuthProvider component"), the built-in STT struggles with non-dictionary terms. Windows Voice Typing handles these more reliably due to its broader language model and adaptive learning.
3. Accessibility and ergonomic needs — Users with RSI or other conditions that make extended typing painful rely heavily on voice input. Unreliable transcription that requires constant manual correction negates the accessibility benefit entirely. A accurate native implementation makes voice input a viable primary input method rather than a frustrating novelty.
4. Offline and low-bandwidth environments — Developers working on aircraft, in rural areas, or behind restrictive firewalls can still use voice input through the OS-native API without requiring a network round-trip to an external STT service.

Additional Context

A functional workaround exists today using a ~30-line AutoHotkey v2 script that unbinds Claude Code's built-in voice:pushToTalk keybinding and remaps spacebar-hold to trigger Windows Voice Typing (Win+H). The script differentiates between a quick spacebar tap (types a normal space) and a hold (activates voice typing), preserving normal input behavior.

The fact that this minimal script delivers a materially better experience than the shipped feature suggests the complexity is in the current approach, not the problem. Delegating to the OS-native API would reduce code, reduce bugs, and improve the user experience simultaneously — a rare case where the simpler solution is also the better one.