Mouse-tracking/focus-reporting escape sequences leak into prompt after opening plan in VS Code (ruled out extension, VS Code, useTerminal, hooks, stuck pty)

Summary

Mouse-tracking / focus-reporting escape sequences leak into the Claude Code CLI prompt (garbled characters, input frozen) after opening a plan/diff in VS Code, then returning focus to the terminal. Matches the root cause described in #50032 (closed as duplicate of #42606, which was auto-closed for inactivity without a fix landing).

Environment

• Claude Code CLI: 2.1.206 (Homebrew cask, installed 2026-07-21)
• Claude Code VS Code extension: 2.1.217 (downgraded from 2.1.218, no change in behavior)
• VS Code: downgraded to 1.129.1 (from 1.130.0, build date 2026-07-22T14:55:04Z), no change in behavior
• Terminal: iTerm2 3.6.11 (standard mouse-reporting profile settings: Mouse Reporting on, allow clicks/drags on, allow wheel on)
• OS: macOS Tahoe, no OS update on the day symptoms began

Notable timing

• VS Code core auto-update applied (Electron binary re-stamped): 2026-07-23 03:43:40
• Claude Code VS Code extension auto-update applied: 2026-07-23 03:43:44 (4 seconds later, same relaunch cycle)
• Symptom onset: same day, after this update cycle — previously worked fine with the prior versions

Steps to Reproduce

1. Run claude in iTerm2 (TUI mode, default or fullscreen/alt-screen).
2. Enter plan mode / open a diff, trigger "Open in IDE" (or Ctrl+G) to open it in VS Code.
3. While VS Code has focus, move the mouse or scroll in the terminal pane behind it (or interact normally in VS Code).
4. Close/return focus to the Claude Code terminal.
5. Observe: garbled escape-sequence characters appear in the prompt; keyboard input stops working. reset recovers the terminal.

What I've ruled out

• Not CLAUDE_CODE_NO_FLICKER (unset in this environment) — rules out the specific trigger named in #42606.
• iTerm2 profile mouse-reporting settings are standard/default, unchanged recently.
• No keyboard/mouse remapping utilities (Karabiner, BetterTouchTool, Hammerspoon, etc.) running.
• No relevant launch agents changed recently.
• Downgrading the Claude Code extension (2.1.218 → 2.1.217) — no change.
• Toggling claudeCode.useTerminal off — no change.
• Downgrading VS Code core itself (1.130.0 → 1.129.1) — no change.
• A third-party tool (Vibe Island) that hooked every Claude Code lifecycle event and set "tui": "fullscreen" in ~/.claude/settings.json was suspected — its hooks, statusLine, and the fullscreen override have since been removed entirely (confirmed via ~/.claude/settings.json) — no change.
• Confirmed on a fully fresh session: quit iTerm2 completely (all windows), quit VS Code completely, relaunched both, ran claude fresh in iTerm2, opened a plan in VS Code via the IDE integration, interacted with the mouse in VS Code, returned focus to iTerm2 — bug still reproduces. This rules out stuck/corrupted pty state as a confound in all prior negative results.

Suspected cause

Given the fix above rules out extension version, VS Code core version, useTerminal, and stuck terminal state, this points to the general, still-unresolved race condition described in #50032: Claude Code does not disable its mouse-tracking (CSI ?1000h/?1002h/?1003h/?1006h) and focus-reporting (?1004h) modes before handing focus to VS Code, and does not flush the tty input queue on return. Mouse/keyboard events generated while VS Code has focus queue on the shared tty and are read back as literal input once Claude Code resumes. This appears to be inherent to the current CLI/IDE-integration behavior rather than caused by any local configuration.

Related issues

• #50032 (closed as duplicate)
• #42606 (auto-closed for inactivity, not fixed)
• #23581 (feature request: --no-mouse / disable mouse tracking option — not implemented)