anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 17:45:37 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 17:45:37 -05:00
Owner
Copy Link
Copy Source

Originally created by @benceferdinandy-signifyd on GitHub (Jan 12, 2026).

Originally assigned to: @kommander on GitHub.

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

Originally created by @benceferdinandy-signifyd on GitHub (Jan 12, 2026). Originally assigned to: @kommander on GitHub. ## 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: ```json { "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
yindo added the opentui label 2026-02-16 17:45:37 -05:00
yindo commented 2026-02-16 17:45:37 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 12, 2026):

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

  • #6710: Can no longer reject tool calls by pressing Escape (specifically about Escape key regression from the same Permission rework)
  • #3455: Make permissions dialog non-blocking and add modifier key shortcuts (feature request for keyboard shortcuts in permission prompts)
  • #6874: opencode attach crashes with 'session().parentID' error (another regression from the same Permission rework #6319)

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.

@github-actions[bot] commented on GitHub (Jan 12, 2026): This issue might be a duplicate of existing issues. Please check: - #6710: Can no longer reject tool calls by pressing Escape (specifically about Escape key regression from the same Permission rework) - #3455: Make permissions dialog non-blocking and add modifier key shortcuts (feature request for keyboard shortcuts in permission prompts) - #6874: opencode attach crashes with 'session().parentID' error (another regression from the same Permission rework #6319) 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.
yindo commented 2026-02-16 17:45:38 -05:00
Author
Owner
Copy Link
Copy Source

@xuyangyuio commented on GitHub (Jan 27, 2026):

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

@xuyangyuio commented on GitHub (Jan 27, 2026): Also allow looping through options with TAB will be super :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label opentui
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4834
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?