[Bug] Question dialog blocks all messages_page_* keybinds in v1.15.9+ (regressed from v1.15.7)

[rafaelsmgomes]

Description

In v1.15.9 and later, the question/select dialog completely swallows every keybind defined in OPENCODE_BASE_MODE. When a question prompt is active you can no longer scroll the message view at all — neither the literal PageUp/PageDown keys nor any custom remap (e.g. messages_page_up: ctrl+u, messages_page_down: ctrl+d).

This is a regression from v1.15.7 (and earlier). Related issue #23897 reported a narrower variant of the same problem on v1.14.20: at that time ctrl+u (messages_*_up) still worked while the dialog was open and only ctrl+d was hijacked (because app_exit defaults include ctrl+d). In v1.15.9+ both directions are dead, suggesting whatever changed in v1.15.9's "Restore question prompt key handling" commit widened the suppression to all base-mode bindings.

Version-by-version behavior (macOS arm64)

Version	PageUp/PageDown while question open	ctrl+u/ctrl+d remap while question open
1.14.20	scrolls messages (works)	ctrl+u works; ctrl+d cancels question (#23897)
1.15.7	scrolls messages (works)	scrolls messages (works)
1.15.9	dead (no action)	dead (no action)
1.15.10	dead	dead
1.15.11	dead	dead

v1.15.9 changelog entry: "Restore question prompt key handling" — likely the change that regressed the fall-through.

Hypothesis (root cause)

The QuestionPrompt component pushes QUESTION_MODE onto the mode stack via useOpencodeModeStack and registers useBindings({ mode: QUESTION_MODE, enabled: !store.editing, ... }). While QUESTION_MODE is active, unhandled keys do not fall through to OPENCODE_BASE_MODE where messages_page_up, messages_page_down, messages_half_page_up, messages_half_page_down, messages_line_up, and messages_line_down live.

Expected behavior: keys not consumed by QUESTION_MODE should propagate to OPENCODE_BASE_MODE (vim/nvim style mode cascading), so message-view scroll commands remain reachable while answering a prompt.

(Bug reproduces with --pure as well — plugins are not involved.)

OpenCode version

1.15.11 (also confirmed broken on 1.15.10 and 1.15.9)

Steps to reproduce

1. Use this tui.json (the broken behavior also reproduces with default keybinds, but the remap makes it obvious):

   {
     "$schema": "https://opencode.ai/tui.json",
     "keybinds": {
       "messages_page_up": "ctrl+u",
       "messages_page_down": "ctrl+d",
       "app_exit": "ctrl+c,<leader>q"
     }
   }

   (Removing ctrl+d from app_exit is required to isolate the scroll regression from the older #23897 cancel behavior.)

2. Start a session and prompt the agent to ask you a question (any flow that triggers the question tool — e.g. plan-mode confirmation, multi-choice prompt).

3. While the question dialog is rendered at the bottom of the TUI, press PageUp, PageDown, ctrl+u, and ctrl+d (and the default fallbacks ctrl+alt+b, ctrl+alt+f).

Expected: message view scrolls.

Actual: nothing happens. All keys are swallowed by the question dialog mode.

Operating System

macOS 26.5 (build 25F71), Apple Silicon (arm64)

Terminal

Ghostty (with tmux 3.6a)

Related

• [Bug] Ctrl+D keybind ignored during question tool — treated as cancel instead of mapped action #23897 — original narrower report of the same architectural problem on v1.14.20
• [BUG] Question tool takes over command palette dialog #28935 / fix(tui): avoid question taking over open dialog #28936 — related case of QUESTION_MODE hijacking the command palette (different surface, same underlying mode-stack issue)

[github-actions]

For keybind-related issues, please also check our pinned keybinds documentation: #4997

[rafaelsmgomes]

Bisect confirms this regressed in #28835 by @nexxeln (commit 59e486a, shipped in v1.15.9 as the "Restore question prompt key handling" changelog entry).

That PR moved the question prompt bindings from OPENCODE_BASE_MODE onto a new QUESTION_MODE pushed via useOpencodeModeStack. The intent — giving the question its own mode so Enter/Escape/app.exit keep working when another mode is active — is sound, but the side-effect is that every binding still registered under OPENCODE_BASE_MODE becomes unreachable while QUESTION_MODE is on top of the stack. That includes:

• session.page.up / session.page.down (messages_page_up / messages_page_down)
• session.half.page.up / session.half.page.down
• session.line.up / session.line.down
• session.first / session.last
• messages.copy, session.toggle.conceal, etc.

The mode-stack guard in createOpencodeModeStack (packages/opencode/src/cli/cmd/tui/keymap.tsx) requires OPENCODE_MODE_KEY to equal the binding's declared mode:

keymap.registerLayerFields({
  mode(value, ctx) {
    ctx.require(OPENCODE_MODE_KEY, value)
  },
})

When QUESTION_MODE is pushed, the data key flips to "question" and no base-mode binding can fire. There appears to be no fallthrough between stacked modes, and tui.json doesn't expose any user-config path to re-target a binding at a different mode — the mode association is entirely source-side (in packages/opencode/src/cli/cmd/tui/config/keybind.ts the schema is a flat name → BindingValueSchema map with no mode field). So users can't work around this in config; the only workaround today is pinning to v1.15.7 or earlier.

cc @nexxeln (PR author) and @simonklee (assigned on the related #23897).