opencode icon indicating copy to clipboard operation
opencode copied to clipboard

Regression: Permission prompt keyboard shortcuts (enter/a/d) removed in Permission rework

Open benceferdinandy-signifyd opened this issue 3 days ago • 1 comments

Description

The Permission rework (#6319, commit f508d8b9f) removed direct keyboard shortcuts for responding to permission prompts. This is a regression that makes the TUI less efficient to use.

Previous behavior (before Dec 31, 2025)

Permission prompts could be answered with single keystrokes:

  • enter / return → Allow once
  • a → Always allow
  • d → Reject (deny)
  • escape → Reject

Current behavior

Users must now:

  1. Navigate between options using arrow keys (/) or h/l
  2. Press enter to confirm
  3. For "Always allow": confirm again on a second prompt

This adds unnecessary friction, especially for power users who frequently approve permissions.

Why this matters

From the OpenCode philosophy:

A focus on TUI. OpenCode is built by neovim users and the creators of terminal.shop; we are going to push the limits of what's possible in the terminal.

TUI users expect single-keystroke actions and the ability to configure keybindings. The current navigate-then-confirm pattern feels more like a GUI modal dialog than a keyboard-first terminal interface.

Suggested fix

Restore the original keyboard shortcuts in the Prompt component (packages/opencode/src/cli/cmd/tui/routes/session/permission.tsx), and ideally make them configurable via the keybinds config section:

{
  "keybinds": {
    "permission_allow_once": "return",
    "permission_allow_always": "a", 
    "permission_reject": "d,escape"
  }
}

Additional consideration

The old a shortcut triggered "always allow" directly. The new implementation added a confirmation step before applying "always allow". Consider adding a permission_allow_always_force keybind (or config flag) that skips this confirmation for users who want the faster workflow.

Note

The removal of these shortcuts appears to be undocumented. The commit message is simply "permission rework" with no explanation for why the shortcuts were removed, suggesting this may have been an oversight during the refactor rather than an intentional design decision.

References

  • Removed in commit: f508d8b9f9de81091f86c61e1f935934f1599185
  • Part of PR: #6319 (Permission rework)
  • Related keybind issues: #89, #351