Esc (and other keys) delivered with ~1-2s latency to TUI apps while inshellisense is active

Description

When inshellisense is active in my shell, keys sent to a full-screen TUI application running in the same terminal are noticeably delayed. The clearest reproducer is the Esc key in a TUI that reacts to it (e.g. interrupt in opencode / opencode2): the key press is eventually delivered, but it takes roughly 1–2 seconds before the application reacts. Disabling inshellisense removes the delay entirely.

I am not sure whether this is inherent to the way is wraps the PTY, or something that can be tuned (e.g. an ESC / escape-sequence disambiguation timeout), so I am reporting it rather than proposing a fix.

Steps to reproduce

1. Shell with inshellisense active (zsh, source of ~/.local/share/inshellisense/init/zsh/init.zsh in .zshrc).
2. Start a TUI app in that terminal that has an observable Esc action, for example opencode2, and start a long-running turn.
3. Press Esc and observe: the action only takes effect after ~1–2 s.
4. Comment out the inshellisense init line, start a new shell, repeat step 3 in the same app/terminal/session: the action is instant.

I have also observed this in lazygit/lazydocker-style TUIs, though those are less precise to time.

Expected behavior

Either keys are delivered to the wrapped application without a user-visible delay, or there is a documented configuration option to shorten/disable the delay (e.g. not intercepting Esc / reducing the escape-sequence timeout).

Environment

• inshellisense: 0.0.4 (Homebrew, /opt/homebrew/bin/is)
• OS: macOS 27.0 (build 26A428), arm64
• Terminal: Ghostty
• Shell: zsh
• Affected app observed: opencode2 v2.0.3 (TUI)

Related

• #411 — TUI applications (lazygit, lazydocker) have broken layout when running inside an inshellisense session
• #418 — Up/Down arrows navigate suggestions instead of shell history