Skip to content

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

Closed

Description

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

Activity

  1. added
    opentuiThis relates to changes in v1.0, now that opencode uses opentui
    on Jan 12, 2026
  2. github-actions commented on Jan 12, 2026

    @github-actions
    Contributor

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

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

    Feel free to ignore if none of these address your specific case.

  3. xuyangyuio commented on Jan 27, 2026

    @xuyangyuio

    Also allow looping through options with TAB will be super :)

  4. github-actions commented on Mar 29, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

opentuiThis relates to changes in v1.0, now that opencode uses opentui

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions