fix(hermes-ink): suppress SGR mouse fragments split across flush boundaries by Mamidi7 · Pull Request #29337 · NousResearch/hermes-agent

Mamidi7 · 2026-05-20T14:34:36Z

Problem

When the Hermes TUI has been running for a few hours, moving the mouse cursor over the terminal window causes literal text like 46M35;40M35 to appear in the input box.

Root cause

Ink enables MOUSE_ANY (DEC 1003) during alt-screen — every pixel of mouse movement generates an SGR mouse event (\x1b[<btn;col;rowM). This is intentional for click/drag/hover support in the TUI.
The 50ms flush timer can split events across stdin chunks — when a heavy React commit blocks the event loop (rendering a large message, tool output, scrolling), the flush timer fires mid-sequence. The incomplete escape sequence is flushed as a sequence token, and the remainder arrives as a text token with no ESC prefix.
Existing guard only catches one split boundary — the existing InputEvent guard (/^\[<\d+;\d+;\d+[Mm]/) catches the case where ESC alone is flushed and the full 3-field [<btn;col;rowM fragment arrives intact. But it misses:
- 2-field fragments (e.g., ESC[<0; flushed → text 35;46M)
- 1-field fragments (e.g., ESC[<0;35; flushed → text 46M)
Text fragments reach InputEvent with empty key name — parseKeypress does not recognize these ESC-less text chunks, so it returns a default key with name=. The existing guards cannot filter them because keypress.name is falsy.

Symptoms

Values like 46M35;40M35 appear in the input box when moving the mouse cursor
Happens more frequently as the TUI accumulates React commits (longer sessions)
No [ or < symbols — only alphanumeric + semicolon separators
Arrow key input is unaffected

Fix

Add two guards in InputEvent.parseKey() after the existing 3-field SGR mouse fragment guard:

2-field guard (/^\d+;\d+[Mm]$/): catches fragments like 35;46M that lost both the ESC and the [< prefix during a split at the second semicolon boundary.

1-field guard (/^\d+[Mm]$/): catches fragments like 46M from a deeper split at the last semicolon boundary.

Both guards use the !keypress.name precondition, ensuring intentionally typed input like 46M (where parseKeypress sets name=m) is not suppressed — only unparseable fragment artifacts.

Verification

Input	`keypress.name`	1-field guard	2-field guard	Leaks?
`46M` (fragment)	``	Match → suppressed	—	No
`35;46M` (fragment)	``	—	Match → suppressed	No
`46M` (typed)	`m`	`!name` fails → skip	—	Yes (correct)
`test` (typed)	``	No match	No match	Yes (correct)

…daries When AlternateScreen is active, Ink enables MOUSE_ANY (DEC 1003) so the TUI can handle click/drag/hover events. The app's 50ms flush timer can fire while an SGR mouse event (ESC[<btn;col;rowM) is still arriving on stdin, splitting the escape sequence across two stdin chunks. The tokenizer handles the first chunk (e.g. ESC[<0;35;) correctly as a sequence token, but the remainder ('46M') arrives as a text token with no ESC prefix — so parseKeypress never enters its ESC-anchored regexes and returns a default key with name=''. The existing InputEvent guard (/^\[<\d+;\d+;\d+[Mm]/) only catches the specific split where ESC alone is flushed and the full 3-field fragment arrives intact. It misses: - 2-field fragments: ESC[<0; flushed -> text '35;46M' - 1-field fragments: ESC[<0;35; flushed -> text '46M' Add two additional guards that match these partial fragments. The !keypress.name gate ensures typed input like '46M' (where parseKeypress sets name='m') is not accidentally suppressed. Fixes #39379

alt-glitch · 2026-05-20T14:57:15Z

Part of the SGR mouse fragment hardening chain: #17701 → #18113 → #26781 → #28463 → this PR. Addresses remaining edge cases from tracking issue #18658.

…env values When TERMINAL_ENV is set in ~/.hermes/.env (e.g. from a previous Docker setup) but absent from config.yaml's terminal section, load_cli_config() skips exporting the config value because _file_has_terminal_config is False and the env var is already set. This leaves a stale TERMINAL_ENV in the environment, causing the terminal backend to silently diverge from what config.yaml says. Fix: add an explicit exception for TERMINAL_ENV in the config→env bridge. This env var selects the terminal backend and should always be controlled by config.yaml. All other terminal env vars (ssh_host, docker_image, etc.) continue to respect the existing design where .env can override defaults when no explicit terminal section exists. Fixes #29186

OutThisLife · 2026-06-04T00:15:17Z

Superseded by #38564.

That PR replaces the three stacked narrow regexes with a single flush-aware guard that also covers the cases this one leaves open:

the flushed CSI prefix (ESC[<0;35;, no terminator) — never matched by /^\d+;\d+[Mm]$/ or /^\d+[Mm]$/
leading-; tails (;46M, ;35;46M) from a split at a semicolon boundary

It also accounts for the upstream parse-keypress.ts burst/fragment recovery (MOUSE_BURST_NOISE_RE et al.) that landed via #35512 after this PR was opened, so prefixed [<...M sequences are now recovered as mouse/wheel events before reaching input-event.ts.

Thanks @Mamidi7 — the root-cause analysis here (1-/2-field flush-boundary splits) is exactly right and carried straight into the replacement. The unrelated TERMINAL_ENV commit (#29186) is intentionally left out of #38564 and should go in on its own.

Closing in favor of #38564.

OutThisLife · 2026-06-04T00:15:18Z

Closing as superseded by #38564.

…rop the regex sink Root-cause fix for the SGR mouse fragment leak (`46M35;40M...` typed into the prompt). The leak was never really about the fragments — it was the flush emitting them. When App's 50ms watchdog fires mid-CSI during a render stall, the tokenizer was force-emitting the buffered partial as a token and resetting to ground, so both the prefix and the ESC-less remainder surfaced as unparseable input. Make the flush state-aware (xterm.js discipline): a bare ESC still flushes to the Escape key (the legitimate ESCDELAY case), but a buffer still inside a multi-byte control sequence (csi/osc/dcs/apc/ss3/intermediate) is NOT emitted — it's kept so the continuation reassembles on the next feed. A one-tick truncation valve in createTokenizer.flush() drops a partial that survives a second flush with no progress, so a genuinely truncated write can't fuse into the next keypress. With partials never entering the input stream, the downstream scrubber is dead code: remove the SGR fragment guard from input-event.ts (both the original `/^\[<\d+;\d+;\d+[Mm]/` and the consolidated form added earlier in this PR). The parse-keypress burst-recovery regexes (MOUSE_BURST_*) are now also redundant but left in place as a safety net for one release; they can be removed in a follow-up once this soaks. Tests: tokenize.test.ts proves a mid-CSI flush keeps/reassembles and that a stale partial is dropped after a second flush and a bare ESC still emits; parse-keypress.test.ts adds the end-to-end split-then-reassemble case yielding a single clean mouse event with no leaked key. Supersedes #29337.

…-leak fix(hermes-ink): reassemble split SGR mouse sequences at the tokenizer (supersedes #29337)

…are rule When App's 50ms flush watchdog fires mid-CSI during a render stall, an SGR mouse report (ESC[<btn;col;row M/m) is split across stdin chunks: the tokenizer force-emits the buffered prefix and resets to ground, so both the prefix and the ESC-less remainder reach InputEvent as nameless tokens. The previous guard only matched a full `[<\d+;\d+;\d+[Mm]` fragment, so the flushed prefixes (`ESC[<0;35;`) and the 1-/2-field and leading-`;` tails (`46M`, `35;46M`, `;46M`) still leaked into the composer as `46M35;40M...` during long sessions. Replace the three would-be narrow regexes with one consolidated rule that covers every split position. A `(?=...\d)` lookahead keeps typed `<`, `[`, `;`, and `M` safe (no coordinate digit), and the embedded M/m terminator in the param class leaves stuck-together fragments / prose intact. The existing `!keypress.name` gate continues to protect real keystrokes, which arrive one char per chunk with a name set. Supersedes NousResearch#29337 (covers the prefix-leak and leading-`;`/1-/2-field tail cases that PR's two added guards missed).

…rop the regex sink Root-cause fix for the SGR mouse fragment leak (`46M35;40M...` typed into the prompt). The leak was never really about the fragments — it was the flush emitting them. When App's 50ms watchdog fires mid-CSI during a render stall, the tokenizer was force-emitting the buffered partial as a token and resetting to ground, so both the prefix and the ESC-less remainder surfaced as unparseable input. Make the flush state-aware (xterm.js discipline): a bare ESC still flushes to the Escape key (the legitimate ESCDELAY case), but a buffer still inside a multi-byte control sequence (csi/osc/dcs/apc/ss3/intermediate) is NOT emitted — it's kept so the continuation reassembles on the next feed. A one-tick truncation valve in createTokenizer.flush() drops a partial that survives a second flush with no progress, so a genuinely truncated write can't fuse into the next keypress. With partials never entering the input stream, the downstream scrubber is dead code: remove the SGR fragment guard from input-event.ts (both the original `/^\[<\d+;\d+;\d+[Mm]/` and the consolidated form added earlier in this PR). The parse-keypress burst-recovery regexes (MOUSE_BURST_*) are now also redundant but left in place as a safety net for one release; they can be removed in a follow-up once this soaks. Tests: tokenize.test.ts proves a mid-CSI flush keeps/reassembles and that a stale partial is dropped after a second flush and a bare ESC still emits; parse-keypress.test.ts adds the end-to-end split-then-reassemble case yielding a single clean mouse event with no leaked key. Supersedes NousResearch#29337.

…are rule When App's 50ms flush watchdog fires mid-CSI during a render stall, an SGR mouse report (ESC[<btn;col;row M/m) is split across stdin chunks: the tokenizer force-emits the buffered prefix and resets to ground, so both the prefix and the ESC-less remainder reach InputEvent as nameless tokens. The previous guard only matched a full `[<\d+;\d+;\d+[Mm]` fragment, so the flushed prefixes (`ESC[<0;35;`) and the 1-/2-field and leading-`;` tails (`46M`, `35;46M`, `;46M`) still leaked into the composer as `46M35;40M...` during long sessions. Replace the three would-be narrow regexes with one consolidated rule that covers every split position. A `(?=...\d)` lookahead keeps typed `<`, `[`, `;`, and `M` safe (no coordinate digit), and the embedded M/m terminator in the param class leaves stuck-together fragments / prose intact. The existing `!keypress.name` gate continues to protect real keystrokes, which arrive one char per chunk with a name set. Supersedes NousResearch#29337 (covers the prefix-leak and leading-`;`/1-/2-field tail cases that PR's two added guards missed).

…rop the regex sink Root-cause fix for the SGR mouse fragment leak (`46M35;40M...` typed into the prompt). The leak was never really about the fragments — it was the flush emitting them. When App's 50ms watchdog fires mid-CSI during a render stall, the tokenizer was force-emitting the buffered partial as a token and resetting to ground, so both the prefix and the ESC-less remainder surfaced as unparseable input. Make the flush state-aware (xterm.js discipline): a bare ESC still flushes to the Escape key (the legitimate ESCDELAY case), but a buffer still inside a multi-byte control sequence (csi/osc/dcs/apc/ss3/intermediate) is NOT emitted — it's kept so the continuation reassembles on the next feed. A one-tick truncation valve in createTokenizer.flush() drops a partial that survives a second flush with no progress, so a genuinely truncated write can't fuse into the next keypress. With partials never entering the input stream, the downstream scrubber is dead code: remove the SGR fragment guard from input-event.ts (both the original `/^\[<\d+;\d+;\d+[Mm]/` and the consolidated form added earlier in this PR). The parse-keypress burst-recovery regexes (MOUSE_BURST_*) are now also redundant but left in place as a safety net for one release; they can be removed in a follow-up once this soaks. Tests: tokenize.test.ts proves a mid-CSI flush keeps/reassembles and that a stale partial is dropped after a second flush and a bare ESC still emits; parse-keypress.test.ts adds the end-to-end split-then-reassemble case yielding a single clean mouse event with no leaked key. Supersedes NousResearch#29337.

…use-fragment-leak fix(hermes-ink): reassemble split SGR mouse sequences at the tokenizer (supersedes NousResearch#29337)

…are rule When App's 50ms flush watchdog fires mid-CSI during a render stall, an SGR mouse report (ESC[<btn;col;row M/m) is split across stdin chunks: the tokenizer force-emits the buffered prefix and resets to ground, so both the prefix and the ESC-less remainder reach InputEvent as nameless tokens. The previous guard only matched a full `[<\d+;\d+;\d+[Mm]` fragment, so the flushed prefixes (`ESC[<0;35;`) and the 1-/2-field and leading-`;` tails (`46M`, `35;46M`, `;46M`) still leaked into the composer as `46M35;40M...` during long sessions. Replace the three would-be narrow regexes with one consolidated rule that covers every split position. A `(?=...\d)` lookahead keeps typed `<`, `[`, `;`, and `M` safe (no coordinate digit), and the embedded M/m terminator in the param class leaves stuck-together fragments / prose intact. The existing `!keypress.name` gate continues to protect real keystrokes, which arrive one char per chunk with a name set. Supersedes NousResearch#29337 (covers the prefix-leak and leading-`;`/1-/2-field tail cases that PR's two added guards missed).

…rop the regex sink Root-cause fix for the SGR mouse fragment leak (`46M35;40M...` typed into the prompt). The leak was never really about the fragments — it was the flush emitting them. When App's 50ms watchdog fires mid-CSI during a render stall, the tokenizer was force-emitting the buffered partial as a token and resetting to ground, so both the prefix and the ESC-less remainder surfaced as unparseable input. Make the flush state-aware (xterm.js discipline): a bare ESC still flushes to the Escape key (the legitimate ESCDELAY case), but a buffer still inside a multi-byte control sequence (csi/osc/dcs/apc/ss3/intermediate) is NOT emitted — it's kept so the continuation reassembles on the next feed. A one-tick truncation valve in createTokenizer.flush() drops a partial that survives a second flush with no progress, so a genuinely truncated write can't fuse into the next keypress. With partials never entering the input stream, the downstream scrubber is dead code: remove the SGR fragment guard from input-event.ts (both the original `/^\[<\d+;\d+;\d+[Mm]/` and the consolidated form added earlier in this PR). The parse-keypress burst-recovery regexes (MOUSE_BURST_*) are now also redundant but left in place as a safety net for one release; they can be removed in a follow-up once this soaks. Tests: tokenize.test.ts proves a mid-CSI flush keeps/reassembles and that a stale partial is dropped after a second flush and a bare ESC still emits; parse-keypress.test.ts adds the end-to-end split-then-reassemble case yielding a single clean mouse event with no leaked key. Supersedes NousResearch#29337.

…are rule When App's 50ms flush watchdog fires mid-CSI during a render stall, an SGR mouse report (ESC[<btn;col;row M/m) is split across stdin chunks: the tokenizer force-emits the buffered prefix and resets to ground, so both the prefix and the ESC-less remainder reach InputEvent as nameless tokens. The previous guard only matched a full `[<\d+;\d+;\d+[Mm]` fragment, so the flushed prefixes (`ESC[<0;35;`) and the 1-/2-field and leading-`;` tails (`46M`, `35;46M`, `;46M`) still leaked into the composer as `46M35;40M...` during long sessions. Replace the three would-be narrow regexes with one consolidated rule that covers every split position. A `(?=...\d)` lookahead keeps typed `<`, `[`, `;`, and `M` safe (no coordinate digit), and the embedded M/m terminator in the param class leaves stuck-together fragments / prose intact. The existing `!keypress.name` gate continues to protect real keystrokes, which arrive one char per chunk with a name set. Supersedes #29337 (covers the prefix-leak and leading-`;`/1-/2-field tail cases that PR's two added guards missed).