[BUG] SGR mouse-tracking sequences leak into the prompt input again on 2.1.220 (Apple Terminal) — regression of #58653 / #49017

Status Closed — duplicate
Reported on v2.1.140
Maintainer reply None cached
Activity 2 comments · opened Jul 27, 2026 · closed Aug 15, 2026

Summary

Mouse wheel / click events are emitted as raw SGR mouse-tracking escape sequences and land as literal text in the Claude Code prompt input, while Claude Code is running.

This is the same failure described in #58653 (closed 2026-05-27, reported on 2.1.140) and #49017 (closed 2026-04-19). Both are closed and locked, and #49017's lock notice asks that a new issue be filed referencing it — hence this report.

Environment

| | |
|---|---|
| Claude Code | 2.1.220 |
| Terminal | Apple_Terminal 470.2 (macOS Terminal.app) |
| TERM | xterm-256color |
| OS | macOS 26.5.2 (Darwin 25.5.0) |
| Shell | zsh |

What is observed

The prompt input fills with sequences like:

❯ <65;40;17M38;23

Decoded, these are SGR extended mouse reports (DEC private mode 1006), CSI < Cb ; Px ; Py M:

<65;40;17M   →  button 65 (wheel down), column 40, row 17, press
38;23        →  truncated fragment of a following report

So mouse tracking is enabled and the events are not being consumed — they fall through to the input buffer as text.

Repro

  1. Run claude in macOS Terminal.app.
  2. Scroll the mouse wheel over the Claude Code TUI.
  3. Observe raw <Cb;Px;Py M sequences appearing in the prompt input.

Notes that may help narrow it

  • Occurs with Claude Code running (not a post-exit terminal-restore problem).
  • Not triggered by abnormal termination — it was already occurring before any process kills or terminal closures in this session, so it is not a SIGKILL/SIGHUP cleanup artifact.
  • This session had 6 concurrent Claude Code sessions running across separate ttys on the same machine, several 2+ days old. Unclear whether concurrency is relevant, but flagging it since #38672 involved "multiple terminals are open" as a factor.
  • Related open issues that look adjacent but are a different environment: #66289 (browser-based terminals / Lightning Studio) and #1509 (random characters in user input area).

Workaround

Disabling all mouse-reporting modes clears it until it recurs:

printf '\033[?1000l\033[?1002l\033[?1003l\033[?1006l\033[?1015l'

(stty sane does not fix it — mouse tracking is a terminal private mode, outside stty's scope. reset works, being heavier-handed.)

What I could not determine

  • Whether the tracking mode is being re-enabled after being cleared, or simply never cleared in the first place.
  • Whether the 6-concurrent-session condition is causal or incidental.
  • Exact trigger point in the session — it was noticed mid-session rather than at a specific action, so I cannot give a deterministic first-occurrence step.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗