tui v2: question prompt steals input from command palette

[damnsamn]

Summary

In the V2 TUI, the visible command palette and an incoming question prompt compete for keyboard input. The palette remains open and visually topmost, but question-mode bindings consume keys, leaving the visible modal and keyboard owner out of sync.

Environment

• opencode version: 0.0.0-next-16339
• OS: Darwin 25.5.0, arm64
• Terminal: Ghostty (TERM_PROGRAM=ghostty, COLORTERM=truecolor); independently reproduced in a private standalone TUI under tmux
• Shell: /bin/zsh
• Install/channel: opencode2, next
• Active plugins: none found in project or user config

Reproduction

1. Start a task that causes the assistant to invoke the question tool after a delay.
2. Open the command palette with Ctrl+P before the question is presented.
3. Wait for the question to appear behind the palette.
4. Press Esc once.
5. Separately, allow a question to become active first and then press Ctrl+P.

Expected Behavior

The topmost visible UI should exclusively own keyboard input. An incoming question should either wait, close or suspend the command palette before taking focus, or remain inactive until the palette closes.

When a question is already active, Ctrl+P should either open the command palette or provide clear modal behavior rather than being silently consumed.

Actual Behavior

If the command palette is open when the question arrives, the palette stays visible over the dimmed question UI, but the question captures keyboard input. Pressing Esc once cancels the question while leaving the visible command palette open.

In the inverse order, pressing Ctrl+P while a question is active does not open the command palette because the question UI consumes the shortcut.

Additional Context

This is consistently reproducible. It was independently reproduced on 0.0.0-next-16339 in a private standalone TUI under tmux with a deterministic delayed question:

1. Prompt the agent to run sleep 5, then invoke the question tool.
2. Open Commands with Ctrl+P while sleep 5 is running.
3. When the question arrives, Commands remains visibly open over Questions.
4. Press Esc; Questions is dismissed and Commands remains open.

Related reports:

• [BUG] Question tool takes over command palette dialog #28935 reports the equivalent command-palette/question conflict in V1.
• Dialogs should keep keyboard focus when a question prompt appears #29999 describes the broader V1 dialog keymap priority problem.
• fix(tui): prevent prompt input behind open modals #36652 covered background prompt input behind V2 modals.
• fix(tui): preserve modal focus across dialog replacement #36656 fixed fix(tui): prevent prompt input behind open modals #36652 by preventing deferred prompt focus restoration while another dialog remains on the stack. That fix does not appear to cover question-mode key routing or global command-palette shortcuts while a question is active.

No workaround has been identified beyond avoiding the command palette while a question may arrive.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [BUG] Question tool takes over command palette dialog #28935: Question tool takes over command palette dialog (V1, same conflict)
• Dialogs should keep keyboard focus when a question prompt appears #29999: Dialogs should keep keyboard focus when a question prompt appears (V1, same root cause)

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