tui: keypad Home and End do nothing in the session prompt #57113

Activity

1. argszero commented on Oct 19, 2026

   

   argszero

   on Oct 19, 2026

   ContributorAuthor

   More actions

   Fix opened in #57114.

   Cause: input.buffer.home / input.buffer.end defaulted to none, so no binding claimed the keypad names in the session prompt. Measured plain Home first, with the transcript jumps unbound — on a two-line prompt with the caret at the end, Home then x gives xaa\nbb, i.e. plain Home is a start-of-buffer move — so the keypad keys are bound to the buffer commands rather than the line commands (ctrl+a / ctrl+e), which would have meant something different.

   The regression test feeds the same CSI 57423 u / CSI 57424 u sequences this report describes and asserts xaa\nbby, so the fix is checked against the exact reproduction.
2. opencode-agent commented on Oct 19, 2026

   

   opencode-agentBot

   on Oct 19, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report and the deterministic reproduction!

   I think this is a duplicate of #55533. That issue reports the same root cause: under the kitty keyboard protocol, NumPad Home/End arrive as kphome/kpend (CSI 57423 u / CSI 57424 u), no default keybind names them, and they get dropped. It also expects every NumPad navigation key to act like its regular counterpart, which includes the session prompt. You're right that PR #55870 doesn't cover input.buffer.home/input.buffer.end. That's a gap in the fix for #55533, though, not a separate problem, so your PR #57114 can address it under #55533.

   Possible duplicates and related issues, ordered from most to least likely:

   • tui: NumPad End/Home ignored under kitty keyboard protocol (Windows Terminal reports KP_END 57424) #55533: NumPad Home/End are ignored under the kitty keyboard protocol because no default binds the kp* names; same cause and symptom, and its expected behaviour covers the prompt
   • fix(tui): bind keypad mirrors for navigation keybinds #55870: the PR fixing tui: NumPad End/Home ignored under kitty keyboard protocol (Windows Terminal reports KP_END 57424) #55533 by adding keypad mirrors to the navigation defaults; it leaves out the prompt's buffer home/end commands
   • Using Home/End to move cursor to start or end of line breaks after submitting prompt #56890: plain Home/End scroll the transcript instead of moving the caret after the first prompt (same Home/End-in-prompt area)
   • Numpad keys not working in TUI prompt and dialogs #20461: earlier v1 report of NumPad keys being ignored in the TUI prompt

   Until a fix lands, you can bind the keypad keys yourself in your TUI config:

   "keybinds": {
     "input.buffer.home": "kphome",
     "input.buffer.end": "kpend"
   }

   The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
3. opencode-agent

   added

   pending close

   triaging

   on Oct 19, 2026
4. opencode-agent

   closed this as duplicateon Oct 20, 2026
5. opencode-agent commented on Oct 20, 2026

   

   opencode-agentBot

   on Oct 20, 2026 – with OpenCode Agent

   Contributor

   More actions

   Closing this as a duplicate of #55533, since there hasn't been a reply in the past day explaining how it differs. Both are about NumPad Home/End (kphome/kpend) being dropped because no default keybind names them. Please follow #55533 for updates. Your PR #57114 can address the prompt's input.buffer.home/input.buffer.end gap there.

   Until a fix lands, binding "input.buffer.home": "kphome" and "input.buffer.end": "kpend" in your TUI config should work around it. If this turns out to be a different problem, reply here and it can be reopened. Thanks again for the clear reproduction!