Pasting an image during a focus change wedges the input loop — terminal floods prompt with SGR mouse escape sequences, Ctrl-C swallowed

What happened

While typing a prompt in a session that had the claude-in-chrome MCP server connected, I went to paste an image into the prompt. At that moment a Chrome window popped to the foreground (the session had previously invoked a claude-in-chrome tool). The focus change happened mid-paste, and from that point the terminal's mouse-tracking mode stayed enabled while Claude Code was no longer consuming the events.

The result: every mouse movement over the terminal was injected into the prompt as a raw SGR mouse escape sequence. The input buffer filled with thousands of sequences like:

^[[<35;53;28M^[[<35;54;28M^[[<35;55;28M^[[<35;56;28M ...
^[[<55;137;42M^[[<55;136;42M^[[<55;134;40M ...
^[[27u  (kitty keyboard-protocol key-release also leaked in)

These were interleaved character-by-character into my actual typed message, e.g. the buffer contained:

lots of stuff is wrong! ... here is the9full^image;try2again<and5try7to[make;it;perfect...

The input loop then became completely unresponsive. The claude process was alive but idle (0% CPU, sleeping S+) — it was no longer reading keystrokes. None of the following reached the app:

• Ctrl-C (clear input)
• Ctrl-L (redraw)
• bracketed-paste-end terminator ESC[201~
• plain printable text

The only thing that recovered it was sending SIGINT directly to the PID from another terminal, which flushed the buffered junk and dropped to the resume screen. The session itself was intact and resumed fine with claude --resume <id>. The in-progress message and the image attachment were lost.

Impact

• A single paste with the mouse near the terminal can fully wedge the input loop, with no in-band recovery (Ctrl-C/Ctrl-L/Esc all swallowed).
• Users without shell access to kill -INT <pid> would have to force-kill the session.
• Appears tied to: mouse-tracking mode being left enabled + a focus/window change during paste (here triggered by a claude-in-chrome popup), so bracketed-paste / mouse-report state desyncs.

Steps to reproduce (observed)

1. Run a session with the claude-in-chrome MCP connected; trigger a tool that opens/raises a Chrome window.
2. Begin typing a prompt, then paste an image while/just as the Chrome window takes focus.
3. Move the mouse over the terminal — the prompt fills with ^[[<NN;X;YM SGR mouse sequences and the input becomes unresponsive.

Expected

• Mouse-report / bracketed-paste modes should be restored to a known state after a paste / focus change, and stray mouse-tracking sequences should never be treated as prompt input.
• Ctrl-C should always be able to clear/recover the input regardless of leaked escape state.

Workaround

From another terminal: kill -INT <claude-pid> to interrupt, then claude --resume <session-id>.

Environment

• Claude Code: 2.1.161
• Terminal: kitty 0.45.0 (kitty keyboard protocol enabled)
• macOS 26.2 (build 25C56), Apple Silicon
• MCP servers connected incl. claude-in-chrome