[BUG] Regression in 2.1.269: dictation-tool paste (clipboard + simulated Ctrl+V) not inserted in VS Code integrated terminal (WSL2) — 2.1.268 works

Same regression on Windows native (no WSL), adding a data point and an explanation of why Ctrl+V and Ctrl+Shift+V behave differently in the VS Code terminal on Windows.

Environment

• Claude Code 2.1.269, native installer, Windows 11
• VS Code 1.137.0, integrated terminal, profile PowerShell (terminalShellType == pwsh), extension anthropic.claude-code 2.1.269
• No ~/.claude/keybindings.json, no user/extension keybindings on Ctrl+V or Alt+V, no terminal.integrated.sendKeybindingsToShell / commandsToSkipShell

Symptom

• Ctrl+V in the Claude Code prompt: nothing is inserted (silently).
• Ctrl+Shift+V in the same terminal: pastes fine.
• Alt+V (image paste): works.
• Worked the day before on 2.1.268 in the same terminal; the auto-update 2.1.268 -> 2.1.269 happened that evening (~/.claude/.last-update-result.json: "version_from":"2.1.268","version_to":"2.1.269"). VS Code 1.137.0 had been installed three days earlier and was fine with 2.1.268.

Why Ctrl+V and Ctrl+Shift+V take different routes in a PowerShell terminal

VS Code (Windows only) registers a keybinding rule workbench.action.terminal.pastePwsh on Ctrl+V with when: terminalFocus && terminalShellType == 'pwsh' && !accessibilityModeEnabled. Unless the clipboard has no text but has file resources, its handler does not run the clipboard paste; it executes workbench.action.terminal.sendSequence with { text: "\x16" }, i.e. it writes the raw Ctrl+V byte to the pty so that PSReadLine can paste natively. Ctrl+Shift+V is still workbench.action.terminal.paste (bracketed paste through xterm.js).

So when Claude Code runs inside a PowerShell terminal in VS Code, Ctrl+V reaches it as a legacy 0x16 keypress and Claude Code has to read the clipboard itself. That path works on 2.1.268 and does nothing on 2.1.269, while bracketed paste (Ctrl+Shift+V) still works on 2.1.269.

Possible link to the kitty keyboard protocol

2.1.269 sends CSI ? u at startup and enables the kitty keyboard protocol when the terminal answers ("terminals that answer the kitty keyboard query ... now get Shift+Enter and Ctrl+Shift shortcuts" in the changelog). VS Code 1.137 does answer: terminal.integrated.enableKittyKeyboardProtocol defaults to true and is passed to xterm.js as vtExtensions.kittyKeyboard. #93718 reports that setting it to false restored paste on macOS/VS Code.

Result on Windows native with "terminal.integrated.enableKittyKeyboardProtocol": false (new terminal, fresh claude): Ctrl+V pastes again (setting applied, new terminal, fresh claude, still 2.1.269). So on Windows native the regression is also the intersection of 2.1.269 enabling the kitty keyboard protocol in the VS Code terminal: with the protocol on, the raw 0x16 Ctrl+V keypress that VS Code hands to the app in a pwsh terminal is no longer treated as a paste, while bracketed paste (Ctrl+Shift+V) still is. Disabling the protocol in VS Code, or running 2.1.268, restores it.

Third environment on this one, adding two things the thread does not have yet: the regression survives into 2.1.270, and it reproduces under a Git Bash terminal profile, not only pwsh.

Environment

• Claude Code 2.1.270 (native installer, win32-x64, commit 97ecbf7abeb4), Windows 11 Education 26100
• VS Code 1.137.0, integrated terminal, profile Git Bash (terminal.integrated.defaultProfile.windows: "Git Bash"), extension anthropic.claude-code 2.1.270
• Wispr Flow 1.6.827 — the same build as the OP
• terminal.integrated.enableKittyKeyboardProtocol unset (so default true); commandsToSkipShell holds one unrelated Julia entry; no keybindings.json; editor.accessibilitySupport: "off"

Repro matrix — the OP's matrix with 2.1.270 in place of 2.1.269:

| Scenario | Result |
|---|---|
| 2.1.270, dictate into the Claude Code prompt, VS Code integrated terminal | ❌ not inserted |
| 2.1.268 in the same terminal, extension unchanged | ✅ works |
| Plain Git Bash prompt in the same terminal, no Claude Code | ✅ works |
| VS Code editor tab | ✅ works |

So 2.1.270 does not carry a fix, and the failure is again exactly the intersection of the build with the VS Code integrated terminal.

Why the Git Bash profile may be worth a look. The Windows-native analysis in the comment above turns on VS Code's workbench.action.terminal.pastePwsh rule, whose when clause requires terminalShellType == 'pwsh'; its handler sends the raw 0x16 byte rather than pasting, so Claude Code has to read the clipboard itself. That rule does not apply to a Git Bash profile, where Ctrl+V stays workbench.action.terminal.paste and goes through xterm.js as a bracketed paste. The failure here is identical anyway. If the legacy-0x16 route and the bracketed-paste route both fail, whatever 2.1.269 changed is not confined to the pwsh path.

Independent bisection of the boundary. Wispr Flow keeps a local history database that records, per dictation, the target application and why its paste-verification ended. That gives a boundary without having to reconstruct it from memory:

• last successful insert into VS Code 2026-09-11 23:07:09 EDT; first failure 2026-09-12 08:57:40 EDT; zero successes in between or since
• every failing row carries contentObservationEndReason = dictated_text_not_found — Flow pasted, read the target back, and could not find its own text, which is what raises its fallback "copy it yourself" card
• the prior baseline on the same Flow build was 100–220 dictations/day into VS Code at roughly 99% success, and Flow 1.6.827 installed a day before the boundary and logged 102 successful inserts that day

So the dictation tool is exonerated by its own telemetry on both sides of the boundary. Posting the signature in case it saves someone the same bisection: any tool that verifies its paste by reading the target back will report a not-found rather than a paste error, which makes this look like a dictation-tool bug from the outside.

"terminal.integrated.enableKittyKeyboardProtocol": false is not yet tested on this Git Bash setup — happy to add the result if it would help distinguish the two paste routes.

Follow-up to my comment above, which had only tested 2.1.270. I have now retested the middle build: 2.1.269 fails in the VS Code integrated terminal on this machine too, and works in Windows Terminal. So the boundary here is 2.1.268 → 2.1.269, matching the OP exactly, and 2.1.270 carries no fix.

Updated matrix — Windows native, Git Bash profile:

| Build | VS Code integrated terminal | Windows Terminal |
|---|---|---|
| 2.1.268 | ✅ inserts | — |
| 2.1.269 | ❌ silently dropped | ✅ inserts |
| 2.1.270 | ❌ silently dropped | — |

A 19-second correlation. Claude Code's session transcripts (~/.claude/projects/*/*.jsonl) carry a version field on each turn, so the moment a build first served a turn can be read off directly instead of inferred. Cross-referencing that against Wispr Flow's history database:

| | |
|---|---|
| 2.1.269's first session turn on this machine | 2026-09-12T12:57:21.249Z |
| First dictated_text_not_found | 2026-09-12T12:57:40Z |
| | 19 seconds |

Zero successful inserts into VS Code for the remainder of that day and the next, against a prior baseline of 100–220 dictations/day at roughly 99%.

A bisection trap worth flagging for anyone else reconstructing a boundary. The file date under ~/.local/share/claude/versions/ is the download time, not the activation time. 2.1.269 was written at 2026-09-11 15:22 local but did not serve a turn until 2026-09-12 08:57 local — nearly eighteen hours later, because a running session keeps executing the binary it launched with. I first bisected from those mtimes and put the regression in the wrong window, which is also why my comment above tested 2.1.270 rather than 2.1.269. The version field in the session transcripts is the reliable signal; anyone working from file timestamps will land a day early.

OP here — the workaround from the comments above also holds on WSL2, and it survives 2.1.270.

Tested on the machine from the original report (WSL2 Ubuntu, VS Code integrated terminal over Remote-WSL, Wispr Flow). Both directions, with the serving build read off the version field in the session transcript rather than inferred from file timestamps:

| terminal.integrated.enableKittyKeyboardProtocol | build | dictation into the Claude Code prompt |
|---|---|---|
| false | 2.1.269 | ✅ inserted |
| true | 2.1.269 | ❌ silently dropped |
| false | 2.1.270 | ✅ inserted |

The control run with the protocol re-enabled failed exactly where it should, so on WSL2 too the regression is the intersection of the build with VS Code's kitty keyboard protocol — the same conclusion axelboman277 reached on Windows native with a pwsh profile, now confirmed on a third platform and a fourth terminal path.

Practical consequence for anyone hitting this: you do not have to pin the CLI. I had this machine locked to 2.1.268 with DISABLE_AUTOUPDATER=1; with the VS Code setting turned off I could drop the lock entirely and run current 2.1.270 with dictation working.

The cost of the workaround is small but not zero — with the protocol off, the shortcuts 2.1.269 introduced are gone. On this setup that is Ctrl+Shift+B alone; Shift+Enter is unaffected, because it goes through the VS Code keybinding that sends ^[\r rather than through the kitty protocol.

Another Windows-native data point, plus confirmation that the enableKittyKeyboardProtocol workaround holds on an npm global install with cmd / Git Bash / PowerShell profiles.

Environment

• Claude Code 2.1.270 (npm global via nvm4w: C:\nvm4w\nodejs\node_modules\@anthropic-ai\claude-code, native claude.exe wrapper), Windows 11 Pro 10.0.26200
• VS Code <VERSION>, integrated terminal, extension anthropic.claude-code 2.1.270
• Wispr Flow 1.6.827

Symptom

Wispr Flow dictation into the Claude Code prompt is silently dropped. Wispr's "paste last transcript" hotkey into the prompt also does nothing. Manual Ctrl+V and right-click paste both work in the same prompt. Wispr works at a plain shell prompt in the same VS Code terminal and in every other application.

Repro matrix (CLI in the VS Code integrated terminal)

| Build | cmd | Git Bash | PowerShell |
|---|---|---|---|
| 2.1.266 | ✅ inserts | ✅ inserts | ✅ inserts |
|---|---|---|---|
| 2.1.266 | ✅ inserts | ✅ inserts | ✅ inserts |
| 2.1.270 | ❌ silently dropped | ❌ silently dropped | ❌ silently dropped |
| 2.1.270 + "terminal.integrated.enableKittyKeyboardProtocol": false | ✅ inserts | ✅ inserts | ✅ inserts |

2.1.267–2.1.269 not tested here; the OP's boundary (2.1.268 → 2.1.269) sits inside my window.

Ruled out (each tested in isolation, none changed anything)

• Wispr Flow version: downgraded 1.6.827 → 1.6.774 (updater parked), no change
• VS Code extension version: 2.1.270 → 2.1.268 → 2.1.263 with the CLI unchanged, no change
• Running both VS Code and Wispr Flow elevated
• VS Code's default shift+insert → editor.action.clipboardPasteAction binding removed, no change

Wispr Flow telemetry matches @mgkay's signature exactly. Its history DB (%APPDATA%\Wispr Flow\flow.sqlite, table History) logs every dictation into app = "Code" since the regression with contentObservationEndReason = dictated_text_not_found and editDistanceToDictated = NULL, versus trailing_newline_added / edit distance 0 on the same Wispr build before it:

| Day | Dictations into VS Code | Unverified inserts |
|---|---|---|
| 2026-09-08 | 33 | 5 |
| 2026-09-09 | 19 | 3 |
| 2026-09-10 | 32 | 10 |
| 2026-09-13 | 19 | 18 |

Workaround confirmed: "terminal.integrated.enableKittyKeyboardProtocol": false in VS Code user settings, then open a new terminal. Running current 2.1.270 with auto-updates back on and dictation working.