anomalyco / anomalyco/opencode
[FEATURE]: Keyboard-first permission prompts and answer modals in Desktop (visible key hints, Enter/Esc) — replacement for stale-closed #29904
@Brendonovich is already working on this.
Since Aug 22, 2026.
- Dominant language
- TypeScript
- Stars
- 209k
- Forks
- 27.5k
- PR merge metrics
- PR metrics pending
Description
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/Escapeplus 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
- Register rebindable commands for the permission dock (e.g.
permission.allow,permission.allowAlways,permission.deny) wired to the existingdecide()path, so they appear in keybind settings and can be remapped like other commands. - Show the active key on each choice in the UI, so users can see what will happen before pressing it.
- Provide sensible defaults that always work:
Enterfor the safe/default action andEscapefor deny/cancel, both in the permission dock and in question/answer modals. - 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.
- 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
- #29904 — predecessor of this request, closed by the stale bot with an invitation to refile
- #7954 — TUI permission shortcuts removed in a rework and restored
- #9447 — numeric keys for permission requests
- #11515 — tabbing through permissions when prompted
- #29999 — dialogs should keep keyboard focus when a question prompt appears
- #41720 — keyboard navigation broken in settings dialogs
- #43771 — accessibility: proper navigation commands for screen readers
Environment
- App: OpenCode Desktop 1.18.21
- OS: Microsoft Windows 11 Education, 25H2, build 26200.8875
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.