fix(tui): SGR mouse sequence leakage into composer under heavy render in tmux

[Nicolas-Formenton]

Describe the bug

Under heavy render load in hermes --tui (especially inside tmux with mouse tracking enabled), SGR mouse escape sequences leak into the chat composer as visible garbage text. The composer fills with patterns like:

5;34M;34M35;16;35M35;18;35M36M35;23;36M25;36M6M;29;37M5;32;37M5;...

This is NOT model output — it's terminal mouse-report leakage.

Steps to reproduce

1. Start Hermes TUI inside tmux: hermes --tui
2. Ensure mouse tracking is on (default: display.tui_mouse: true)
3. Have a large session (200k+ tokens) so rendering is heavy
4. Move the mouse across the terminal rapidly for several seconds
5. Observe that the composer (❯) fills with numeric garbage matching digit;digit;digitM patterns

Root cause

The mechanism

1. Hermes activates DECSET 1000+1002+1003+1006 (SGR mouse tracking) via ENABLE_MOUSE_TRACKING in packages/hermes-ink/src/ink/termio/dec.ts
2. The terminal responds with SGR mouse reports: \x1b[<btn;col;rowM (press) and \x1b[<btn;col;rowm (release)
3. Under heavy render (React reconciler busy), stdin is not read promptly
4. Mouse events accumulate in the OS tty buffer
5. The 50ms incomplete-escape flush timer in App.tsx (line ~138, NORMAL_TIMEOUT = 50) fires
6. The \x1b prefix is flushed as a lone ESC key event (via input-event.ts)
7. The remaining [<btn;col;rowM arrives as text on the next chunk
8. parseTextWithSgrMouseFragments() in parse-keypress.ts attempts to recover these fragments via SGR_MOUSE_FRAGMENT_RE

Why the current fix is incomplete

The existing fix (commits 71b685aee and ded011c5a) added SGR_MOUSE_FRAGMENT_RE and parseTextWithSgrMouseFragments() to catch orphaned SGR fragments. This works for simple cases but fails when:

1. Extreme concatenation: Under sustained render backpressure, dozens of mouse events pile up. Fragments concatenate without separators, and the regex can't always match overlapping/adjacent fragments correctly.

2. Corrupted fragments: When multiple writes to the composer buffer overlap during re-entry to the event loop, partial fragments get interleaved, producing patterns that don't match any regex (e.g., 37M37M6; — two M final bytes in a row).

Code path

The critical path is in parse-keypress.ts:

stdin chunk → createTokenizer({x10Mouse: true}) → tokens
  → for each 'text' token:
      parseTextWithSgrMouseFragments(token.value)  // tries to recover
        if recovery fails: parseKeypress(token.value)  // falls through
          → default key with name="" → leaks into input

// App.tsx flush timer:
incompleteEscapeTimer → tokenizer.flush()
  → splits ESC from continuation
  → ESC → 'escape' key event
  → '[<...M' → tries parseTextWithSgrMouseFragments

Expected behavior

SGR mouse events should never appear as visible text in the composer, even under extreme render load and tmux.

Suggested improvements

1. Buffer-escaping: If parseTextWithSgrMouseFragments can't recover, strip the pattern rather than letting it leak as visible text (whitelist approach: if text looks like a corrupted SGR mouse fragment, drop it silently)

2. Staggered flush: Instead of always flushing at exactly 50ms, push the timer back up to ~200ms when CSI state is active and stdin data is arriving rapidly (indicates mouse tracking is active)

3. Rate-limit mouse tracking re-assertion: The onStdinResume handler re-enables mouse tracking. Consider adding a cooldown or detecting the leak and temporarily disabling mouse tracking when fragments are detected

4. Disambiguate flush vs keypress ESC: When the flush timer fires with a buffered ESC where the next byte would start a CSI sequence, emit a synthetic "mouse leak detected" event instead of an ESC keypress

Environment

• OS: Linux (WSL2 Ubuntu)
• Terminal: tmux with mouse on
• Hermes version: f98b5d00a (main)
• Session size at time of leak: ~271k tokens

[konsisumer]

This issue appears to describe the same problem as #29557, #31050.
Maintainer might want to consolidate or pick one as canonical.

[iseppe]

This happened to me in WSL2 Ubuntu 24.04 using WezTerm after double clicking on a link

Also, this fixed it for me when you can't send the '/mouse off' command:

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

[reefmind]

Closing as resolved by merged PR(s): #35512, #38564.

[teknium1]

This appears to be implemented on current main by the merged SGR mouse tokenizer fix. Automated hermes-sweeper review.

Evidence:

• fix(hermes-ink): reassemble split SGR mouse sequences at the tokenizer (supersedes #29337) #38564 merged as 92be989291bb57e20937d585d35dd602508c1a99; its implementation commit f3543235475a7edb7a44adc883d97cdebf818cfb is the root-cause fix for split SGR mouse fragments leaking into the prompt.
• ui-tui/packages/hermes-ink/src/ink/termio/tokenize.ts:322 now emits only a bare ESC on flush; when the tokenizer is inside a multi-byte control sequence such as ESC[<btn;col;rowM, it keeps the partial sequence buffered instead of turning it into composer text.
• ui-tui/packages/hermes-ink/src/ink/termio/tokenize.ts:50 adds the truncation valve so an unchanged partial sequence is dropped after a second flush with no continuation.
• Regression coverage in ui-tui/packages/hermes-ink/src/ink/termio/tokenize.test.ts:19 and ui-tui/packages/hermes-ink/src/ink/parse-keypress.test.ts:100 covers the reported ESC[<... + watchdog-flush + continuation path and verifies no text leaks.
• The merge is contained in release tag v2026.6.5.

Thanks to the reporters/commenters for the detailed tmux/WSL repro notes and the link to the resolving PR chain (#35512, #38564).