You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a way to set the escape timeout directly to stdin #63990
Prevent extremely jarring terminal menu behaviour in contexts where "esc" is expected to immediately trigger exit behaviour, whether that's popping up a prompt or invoking process.exit (i.e. almost every terminal menu presented to users).
Especially in combination with input overloading so that "esc", "q", and "ctrl-x" all do the same thing, the fact that everything except escape is instant leads to an incredibly bad user experience.
What is the feature you are proposing to solve the problem?
Add a function to stdin that lets users explicitly set the escape timeout for that input. E.g. stdin.setEscapeTimeout(0)
What alternatives have you considered?
Two alternatives, neither good:
use a custom ReadLine interface with the escapeCodeTimeout value set to zero. This is a hack for any code where "lines" don't mean anything, e.g. terminal menu navigation that relies on direct keyboard input rather than "text input where the user sees what they're typing and signals they are finished via newline".
use a separate stdin.on(`data`, (d) => d.length === 1 && d[0] === 0x1b && process.exit()) event handler on top of keypress monitoring, just so we don't get stuck in whatever code path enforces the 500ms delay before sending "esc" on as keypress event. This works "great", but is obviously also a hack: one should not need "not a keypress listener" just to smooth over a problem with "keypress" =)
My understanding is that the delay is introduced by the escape-sequence parser used by keypress handling rather than by stdin itself. The issue is particularly noticeable for terminal menu applications where Esc is expected to behave as an immediate cancel/exit action, while q or Ctrl+C respond instantly.
Before working on an implementation, would maintainers prefer:
A configurable timeout on the keypress/readline side (similar to escapeCodeTimeout), but available without constructing a readline.Interface; or
A lower-level stdin API that affects escape-sequence parsing globally?
My initial thought is that the timeout belongs closer to the keypress parser than to stdin, since stdin itself cannot know whether an ESC byte is a standalone key press or the beginning of a terminal escape sequence.
Activity
Shivay-98 commentedon Jun 22, 2026
I'd like to investigate this.
My understanding is that the delay is introduced by the escape-sequence parser used by keypress handling rather than by stdin itself. The issue is particularly noticeable for terminal menu applications where
Escis expected to behave as an immediate cancel/exit action, whileqorCtrl+Crespond instantly.Before working on an implementation, would maintainers prefer:
escapeCodeTimeout), but available without constructing areadline.Interface; orMy initial thought is that the timeout belongs closer to the keypress parser than to stdin, since stdin itself cannot know whether an
ESCbyte is a standalone key press or the beginning of a terminal escape sequence.