[BUG] Mouse movement injects SGR escape sequences into chat input in browser-based terminals (Lightning Studio)

Description

When using Claude Code inside a browser-based terminal (Lightning Studio, which uses xterm.js over WebSocket), moving the mouse over the Claude Code TUI injects raw SGR mouse tracking escape sequences directly into the chat input field as literal text.

Steps to Reproduce

1. Open Claude Code v2.1.168 inside a Lightning Studio terminal (browser-based, xterm.js over WebSocket)
2. Start a conversation
3. Move the mouse cursor over the Claude Code chat window

Actual Behavior

The chat input is flooded with raw mouse tracking escape sequences, e.g.:

150;7M149;7M143;7M135;8M119;9M105;10M99;11M95;11M93;11M92;11M91;11M92;11M96;9M98;8M99;7M99;8M97;10M95;12M94;14M93;16M94;17M94...

These appear to be SGR mouse protocol coordinates (\e[<Cb;Cx;CyM) with the escape prefix stripped, injected into stdin as literal text rather than being consumed by the TUI.

Expected Behavior

Mouse movement should not produce any visible output in the chat input field.

Environment

| Field | Value |
|-------|-------|
| Claude Code version | 2.1.168 |
| Terminal | Lightning Studio (browser-based, xterm.js over WebSocket) |
| OS | Linux (cloud-hosted Studio) |

Does NOT reproduce in

• VS Code integrated terminal (native Electron)
• Cursor integrated terminal (native Electron)

Persists across

• Terminal tab refreshes
• New Studio instances

Notes

The issue is specific to browser-based WebSocket terminals. The hypothesis is that Claude Code's TUI enables a mouse tracking mode that the Studio's xterm.js implementation advertises support for, but then forwards the raw escape bytes to stdin as literal text rather than consuming them — which works fine in native Electron terminals (VS Code/Cursor) but breaks in browser-proxied ones.

Possible workaround to investigate: detecting TERM_PROGRAM / terminal capabilities before enabling mouse tracking, or providing a --no-mouse flag.