[FEATURE]: Keyboard-first permission prompts and answer modals in Desktop (visible key hints, Enter/Esc) — replacement for stale-closed #29904 #44246

Problem

In OpenCode Desktop, permission prompts cannot be answered from the keyboard at all, and modal dialogs that ask for an answer are not keyboard-navigable either. Responding requires a mouse click every time, which breaks any keyboard-driven workflow and is an accessibility barrier.

This is confirmed in the current source: packages/app/src/pages/session/composer/session-permission-dock.tsx renders Deny / Allow Always / Allow Once as buttons with onClick handlers — there is no command id and nothing to rebind. A maintainer-confirmed duplicate analysis of this gap previously existed in #29904 before it was auto-closed by the stale bot after 60 days of inactivity, with a request to open a new issue if still relevant. It is still relevant.

For comparison:

• Codex shows the key that will perform each action directly on the choice, so the answer is always one visible keystroke away.
• Claude Code supports answering prompts entirely from the keyboard (Enter / Escape plus numbered choices). Its numbered shortcuts are not always stable between variants of the same prompt, which is worth avoiding as a design detail, but the keyboard-first interaction itself is the right model.

I have summarized this desired interaction model, including the reliability concerns, in CommandCodeAI/desktop#10 for a different agent desktop app; the same design applies here.

The TUI already had this exact feature regress once and get restored (#7954): enter → allow once, a → always, d / esc → deny. Those shortcuts never existed on desktop/web.

Proposal

1. Register rebindable commands for the permission dock (e.g. permission.allow, permission.allowAlways, permission.deny) wired to the existing decide() path, so they appear in keybind settings and can be remapped like other commands.
2. Show the active key on each choice in the UI, so users can see what will happen before pressing it.
3. Provide sensible defaults that always work: Enter for the safe/default action and Escape for deny/cancel, both in the permission dock and in question/answer modals.
4. Keep shortcut meanings stable within a given prompt shape, so repeated muscle memory stays reliable. Consider deliberately leaving "always allow" without a keyboard shortcut, since it is the most consequential action and an accidental keystroke there is costly.
5. Extend the same keyboard treatment to modal dialogs that request typed or selected answers, including focus placement and Tab order.

This remains distinct from permissions.autoaccept (⌘⇧A), which toggles auto-accept mode rather than responding to the pending request.

Related reports

• [FEATURE]: Port permission prompt keyboard shortcuts (allow/deny/always) to the desktop/web app #29904 — predecessor of this request, closed by the stale bot with an invitation to refile
• Regression: Permission prompt keyboard shortcuts (enter/a/d) removed in Permission rework #7954 — TUI permission shortcuts removed in a rework and restored
• [FEATURE]: Allow numeric key press to select permissions requests #9447 — numeric keys for permission requests
• [FEATURE]: Tab through permissions when prompted #11515 — tabbing through permissions when prompted
• Dialogs should keep keyboard focus when a question prompt appears #29999 — dialogs should keep keyboard focus when a question prompt appears
• Keyboard navigation completely broken in General/Shortcuts/Providers/Models dialogs (arrows, PgUp/PgDn not working) #41720 — keyboard navigation broken in settings dialogs
• [Accessibility]: Add proper navigation commands and cursor for screen-readers #43771 — accessibility: proper navigation commands for screen readers

Environment

• App: OpenCode Desktop 1.18.21
• OS: Microsoft Windows 11 Education, 25H2, build 26200.8875