Input corruption: first keystrokes at a fresh prompt scrambled in VS Code integrated terminal (Windows)

Status Open
Reported on v2.1.195
Maintainer reply None cached
Activity 4 comments · opened Jun 29, 2026

Summary

Typing at a fresh Claude Code prompt inside the VS Code integrated terminal on Windows corrupts the first 1-2 keystrokes (phantom space/backspace or character reorder). After the first characters, the rest of the line is clean. Does not happen in standalone Windows Terminal / PowerShell.

Repro

  1. Run claude in the VS Code integrated terminal (PowerShell) on Windows.
  2. At a fresh prompt, type a short sentence at normal speed, e.g. Did not fix it.
  3. The first characters scramble: Did renders as D id (phantom space after the first char). Another observed case: I did -> DI did.

Expected

Text appears exactly as typed.

Actual

First 1-2 characters are reordered / gain a phantom space or backspace; the remainder of the line is correct.

Environment

  • Claude Code: 2.1.195
  • VS Code: 1.122.1
  • OS: Windows 10 (19045)
  • Shell: PowerShell (pwsh)

Already tried (no effect)

  • terminal.integrated.windowsUseConptyDll: both true and false
  • editor.accessibilitySupport: off (status bar had shown "Screen Reader Optimized")
  • terminal.integrated.localEchoEnabled: off
  • terminal.integrated.shellIntegration.enabled: false
  • terminal.integrated.gpuAcceleration: off and auto

Notes / suspected cause

Clean in standalone Windows Terminal, broken only in the VS Code integrated terminal, and only for the first keystrokes at prompt-start. This is consistent with the TUI's terminal query at prompt-draw (cursor-position / device-attributes request) having its reply injected into the input stream and colliding with the user's first keystrokes, with VS Code's xterm.js reply timing differing from a native Windows console.

View original on GitHub ↗

4 Comments

github-actions[bot] · 2 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/13345
  2. https://github.com/anthropics/claude-code/issues/17787
  3. https://github.com/anthropics/claude-code/issues/18234

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

m-selig · 2 months ago

👎

suporte2-cpu · 1 month ago

Still reproduces on 2.1.210, three releases after this was filed. I can also add a second affected host: Cursor 3.11.19, a VS Code fork. It uses the same xterm.js-based integrated terminal, which I think strengthens the CPR-collision hypothesis in the original report rather than pointing at anything specific to VS Code itself.

Environment

  • Claude Code: 2.1.210 (via the Cursor extension anthropic.claude-code-2.1.210-win32-x64)
  • Host: Cursor 3.11.19 (VS Code fork, xterm.js integrated terminal)
  • OS: Windows 10 Pro 19045
  • Shell: PowerShell

One detail that "scrambled" may not capture: in my case the stray first character is undeletable — backspace will not remove it. That reads as the reply to the prompt-draw cursor-position query (ESC[6nESC[row;colR) landing in the buffer as something the line editor doesn't treat as user-typed text, rather than as a reordering of the user's own keystrokes. Mentioning it in case it helps narrow down where the reply is (or isn't) being consumed.

For what it's worth, nothing in the 2.1.207–2.1.210 changelogs appears to touch this, and the VS Code settings listed in the original report have no effect here either.

sixbacon · 1 month ago

Confirming the same corruption on a different machine, and on a newer build than the OP:

  • Claude Code: 2.1.207
  • OS: Windows 10 Home (19045)
  • Terminal: VS Code integrated terminal, PowerShell
  • Started within the last couple of days (was fine before)

Symptoms match the OP: the first 1-2 keystrokes at a fresh prompt scramble, e.g. typing feedback renders as f eedback (phantom space after the first character). The first character also appears stuck on the display - trying to backspace over it deletes a different character, so the visible line and the input buffer disagree about position.

One additional symptom not in the OP: sometimes the prompt stops responding to typing entirely, and only recovers after cycling through a slash command (e.g. /usage, dismiss the dialog). That feels consistent with the suspected cause in the OP notes - a terminal query reply colliding with the input stream and leaving the input state machine mid-sequence until something forces a redraw.