tui: question tool custom-answer input drops keystrokes and freezes #51294

Activity

1. github-actions

   assigned

   simonklee

   on Sep 25, 2026
2. github-actions

   added

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   and removed

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Sep 25, 2026
3. github-actions commented on Sep 25, 2026

   

   github-actionsBot

   on Sep 25, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for updating the issue — the report now includes the required description, reproduction steps, and system information.
4. tomimelo commented on Oct 26, 2026

   

   tomimelo

   on Oct 26, 2026

   More actions

   Same here. I think those are not "random" keys. As far as I tested, h j k l keys (the ones used to cursor navigation in vim) are dropped and you cannot type properly

   👍React with 👍1Reacted by John
5. Saka-CS commented on Oct 27, 2026

   

   Saka-CS

   on Oct 27, 2026

   More actions

   Checked this on v2.1.2 (Linux, Ghostty 1.3.1, Hyprland; isolated server + TUI attached with --server) and could not reproduce the dropped keystrokes.

   • Question form with a custom-answer row ("Type your own answer"), entered edit mode on that row, typed a 24-character string: all 24 characters registered, no freeze, no dropped keys.
   • Also re-checked the related tab-switch trap from TUI: question dialog keyboard trapped after switching tabs while custom-answer field is focused #47624: with the custom-answer field in edit mode, switching tabs and then pressing Down / Escape still worked; the dialog never became keyboard-dead.
   • 0 FormNotFoundError or other form errors in the client log during any of this.

   So on 2.1.2 I can't confirm the 2.0.16 regression here. If it still happens, it may depend on terminal/IME details (the original report used tmux + TERM=xterm-256color, mine is Ghostty with TERM=xterm-ghostty), so a --print-logs/debug capture from an affected run would probably help more than another environment confirmation.

   Note: the forms in this test were created via POST /api/session/{id}/form rather than by the model calling the question tool, but that is the same form/input layer the dialog renders.
6. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the detailed report. I tried to reproduce this on v2.0.16 on Linux with a simulated model calling the question tool:

   • A single question: I moved to "Type your own answer", pressed Enter and typed hello jkl world one key at a time.
   • Two questions (with tabs and the Submit step): I typed both slowly and in fast bursts like hjkl hjkl, and also started typing straight from the option list.

   Every character showed up, including h, j, k and l (another commenter said those were the dropped keys). The field never froze, and the review step showed the answers exactly as typed.

   The one thing I couldn't match is tmux: my test terminal didn't go through tmux, so tmux may be what triggers this. To help narrow it down:

   1. Does it still happen on the latest release (opencode upgrade)?
   2. Does it happen in the same terminal outside tmux?
   3. Your tmux version and any relevant settings (e.g. extended-keys, escape-time, set -g default-terminal), and which terminal emulator tmux runs in.
   4. Is it a single question or several (with tabs)? Do you open the field with arrow keys + Enter, by clicking, or by just starting to type?
   5. If possible, a log from an affected run (opencode --print-logs 2> opencode.log) and a short screen recording showing which keys go missing.

   Related issues: #47624 (keyboard trapped in this field after switching tabs, fixed in v2), #43376 (question dialog hang, v1).