Simulated Ctrl+V paste (Wispr Flow voice dictation) broken on Windows since v2.1.83
Status Closed — not planned
Reported on v2.1.81
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 16 comments · opened Mar 25, 2026 · closed May 28, 2026
Description
External voice dictation tool Wispr Flow stopped injecting text into the Claude Code prompt after auto-updating to v2.1.83.
Environment
- OS: Windows 11 Home 10.0.26200
- Shell: bash (VS Code integrated terminal + standalone Command Prompt — same behavior in both)
- Claude Code: v2.1.83
Observed Behavior
- Wispr Flow text injection → does not work in v2.1.83 ❌
- Manual Ctrl+V paste → works in v2.1.83 ✅
- Wispr Flow text injection → works in v2.1.81 ✅
- Wispr Flow works in all other applications (outside Claude Code) ✅
Steps to Reproduce
- Install Wispr Flow
- Open Claude Code v2.1.83
- Activate Wispr Flow dictation in the Claude Code prompt
- Release dictation — text is not inserted
Regression Confirmed
Downgrading to v2.1.81 via npm install -g @anthropic-ai/claude-code@2.1.81 immediately resolves the issue. Upgrading back to v2.1.83 breaks it again.
Related Issues
- #37932 — Synthetic key event input broken (VoxType, Linux)
- #37095 — Win+H voice typing broken on same Windows build
- #38577 — Voice push-to-talk regression in v2.1.83
16 Comments
Same area, different environment: on macOS (Darwin 25.3.0), pressing Cmd+V in the Claude Code TUI running inside the VS Code integrated terminal types a literal v instead of pasting. Manual paste via right-click works fine. Cmd+V works normally in the VS Code terminal itself outside of Claude Code.
Confirming regression on macOS — v2.1.83 paste broken
Environment:
Observed behavior:
Regression confirmed: Running a parallel session on v2.1.81 in the same machine — paste works fine. The issue is isolated to v2.1.83.
This aligns with @LangeMoritz's macOS report above and suggests the regression is cross-platform, not Windows-specific. The common denominator is v2.1.83's input handling changes affecting paste/simulated key events across all platforms.
Workaround: Downgrade to v2.1.81 via
claude update --version 2.1.81.Confirming regression
Environment:
Confirmed: Same issue on v2.1.83. Downgrading to v2.1.81 resolves it.
Confirming as well
downgrading to x.x.81 worked
I confirm the same behavior.
Confirming the same behavior.
Downgrading to v2.1.81 resolved it.
Confirming the regression. Windows with VS Code. Downgrading to 2.1.81 does not solved the issue.
Same issue:
VS code version: 1.113.0 (user setup)
Commit: cfbea10c5ffb233ea9177d34726e6056e89913dc
Date: 2026-03-24T15:07:18+01:00
Electron: 39.8.3
ElectronBuildId: 13620978
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19045
Confirming this on macOS as well.
Environment:
Behavior: Wispr Flow's "Press Enter" voice command does not register inside Claude Code. Regular dictation (typing words) works fine. The same command works in every other app and in the terminal outside of Claude Code.
The downgrade workaround is not a real solution. Asking users to pin to v2.1.81 indefinitely means missing every future update. This is a regression in the input handler introduced in v2.1.83 - it should be fixed forward in the next release, not worked around by rolling back. Voice input tools (Wispr Flow, SuperWhisper, Monologue) are a growing part of how people use terminal apps. This needs a proper fix.
Filed separately as #39983 before finding this thread.
Still broken on v2.1.92, Windows 11 Pro (10.0.26200), bash shell in Windows Terminal.
Affected tools: Wispr Flow — simulated paste/text injection completely dead. Voice-dictated text never arrives in the Claude Code input. Works fine in every other application on the same machine.
Built-in /voice: Also unreliable on this platform — spacebar hold detection frequently fails to activate recording.
This has been broken since v2.1.83 with no maintainer response. Voice input is a core workflow for many users — would appreciate this getting prioritized.
Still broken in v2.1.111 (latest as of today, 2026-04-16) on Windows 11. Confirming this regression is unresolved ~2 months after the report.
Real-world impact for high-volume voice users:
I rely on Wispr Flow for the majority of my input to Claude Code (heavy daily usage). With this bug, every dictated message gets
truncated at the start — only the tail end of the text actually arrives in the prompt. Even manually re-pasting the captured
transcript exhibits truncation in the TUI on Windows.
Why the suggested downgrade isn't a viable workaround:
v2.1.81 is now ~30 releases behind. Pinning to it means giving up two months of fixes, features, and security updates just to keep
voice input working. For users who depend on dictation, this is effectively "stop using Claude Code on Windows."
This may be part of a broader pattern:
A second Windows paste regression was reported in #47799 (paste broken in claude login since 2.1.105+, closed as duplicate of
#47699). Together with #37095, #37932, and #38577, this points to a recurring fragility in TUI input handling on Windows — would be
worth treating as a class of bugs rather than individual regressions.
Would really appreciate prioritization here. Happy to provide additional repros, logs, or test pre-release builds if it helps.
Is there any update on this? I'd really appreciate it being prioritised. It's having a massive productivity impact on me.
My only workaround so far is to use
/voice, but that functionality is nowhere near as good as Wispr Flow and is not yet a productive experience.I had the same issue with Claude Code on VS Code not accepting Wispr Flow through the terminal. I am now on 2.1.118 and it is working again for me. this was potentially fixed with a terminal rework in 2.1.116. I was on 2.1.81 as well and tested the upgraded again today 4/23/2026
That's an interesting @jaybazile. I was already running. 2.1.118 and still had the issue. I uninstalled, restarted my machine, and reinstalled native on Windows, and it works now.
I had already uninstalled and reinstalled before, but not without restarting my machine in between, so maybe there was an oddity there.
The version I'm running now is 2.1.119, so I can't be 100% sure that it was fixed by 118, but anyway, it's working now!
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.