Random "-" character submitted as message — VT100 ESC O m sequence misinterpreted as text input

Resolved 💬 3 comments Opened Mar 31, 2026 by oierlaraudogoitia Closed Apr 4, 2026

Version: 2.1.88

Description:
Occasionally a bare - character is sent as a message without the user intentionally typing it.

Root cause (found via bundle analysis at cli.js line 546):

The keypress parser's raq lookup table maps the VT100 application keypad minus escape sequence (Om) to the string "-":

raq = { ..., Om: "-", OM: "return", ... }

The lX_() function then passes it through as text input:

if (_.startsWith("O") && _.length === 2 && q.name && q.name.length === 1)
  _ = q.name, z = true;

Since OM maps to "return" (Enter), if the terminal sends ESC O m followed by ESC O M (application keypad minus + application keypad Enter), that produces - inserted into the input and then immediately submitted.

Likely trigger: Mouse button release events use SGR format ESC [ < N ; X ; Y m (ending in lowercase m). If a partial sequence or buffering issue causes ESC O to remain in the input buffer and then m arrives (from a mouse release event), it forms ESC O m-. Combined with ESC O M for keypad Enter, this auto-submits a bare dash.

Suggested fix:
In lX_(), when an O<letter> sequence resolves to a single numpad symbol character (-, +, *, /, ., ,, 0-9), only emit it as text if the terminal is confirmed to be in application keypad mode (DECKPAM active). Otherwise suppress it to avoid ghost characters being injected into the input.

Workaround: printf '\033[?1000l' to reset mouse tracking state.

Environment: macOS 25.2.0 (Darwin), zsh terminal, npm package installation

View original on GitHub ↗

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