[BUG] Mouse/focus escape sequences dump into input on window resize (WSL2, v2.1.195)

Environment

• Claude Code version: 2.1.195
• OS: WSL2 (Linux 6.18.x microsoft-standard-WSL2) on Windows, Windows Terminal
• Shell: bash

Summary

During a session, resizing the terminal window (also reproduces on subprocess exit and suspend/resume) causes mouse-tracking and focus-reporting escape sequences to be printed literally into the prompt input box. Once it happens the input is effectively unusable — every subsequent mouse movement or scroll injects more escape-sequence text into the composer, e.g.:

[<35;88;12M  [<35;89;12M  [<32;90;13M
[I  [O

The TUI appears to leave terminal tracking modes asserted (mouse ?1000/?1002/?1003/?1006, focus ?1004) and does not re-sync/clean them when the terminal state changes, so raw sequences land in the input queue and are rendered as text.

Steps to reproduce

1. Start claude in WSL2 / Windows Terminal.
2. During an active session, resize the terminal window (or suspend with Ctrl+Z and fg, or exit a subprocess that enabled mouse mode).
3. Move/scroll the mouse over the terminal.

Expected

Mouse and focus tracking modes are correctly re-asserted/cleaned across resize, subprocess transitions, and suspend/resume; no raw escape sequences appear in the input.

Actual

Raw mouse/focus escape sequences are printed into the input box; the prompt becomes unusable until the terminal modes are reset.

Workaround

Blind-typing reset, or:

printf '\e[?1000l\e[?1002l\e[?1003l\e[?1006l\e[?1004l'

restores input — confirming this is a tracking-mode cleanup issue rather than a rendering one.

Notes

• Does not reproduce on native Linux/macOS terminals for the same workflow — appears WSL2/Windows-specific.
• Related: #10375 (focus escape sequences in input, still open), #67300 (WSL2 scroll-wheel regression, closed), #50032 (external-editor mouse leak, closed). This report covers the window-resize / state-change trigger on v2.1.195, which is still reproducible after those.