Repository navigation
Description
Description
Title:
TUI permission dialog can become stale: Enter confirm does nothing while /permission returns
Description:
OpenCode TUI can get stuck on a permission prompt even though the server has no pending permission requests.
Environment:
- OpenCode: 1.15.5
- OS: Linux 5.4.0-216-generic x64
- tmux: 3.2a
- TERM inside tmux: tmux-256color
- Client terminal: xterm-256color
- Running mode:
opencode --port 9888, with additionalopencode attach http://127.0.0.1:9888/ ...panes - Plugins:
- [email protected]
- file:///host/lab-di/hi.choi/workspace/db_ontology/.opencode/plugins/wiki-session.ts
Observed behavior:
The TUI shows:
Permission required
→ Read .env
Path: .env
Allow once / Allow always / Reject
enter confirm
Arrow/tab selection works, and Enter itself works elsewhere, but pressing Enter on the selected permission option does not dismiss the dialog and does not continue
execution.
Important diagnostic detail:
While the TUI still displayed the permission dialog, the local server reported no pending permissions:
The server health endpoint was fine:
GET http://127.0.0.1:9888/global/health
=> {"healthy":true,"version":"1.15.5"}
This suggests the TUI has an orphaned/stale permission overlay whose backing permission request has already been resolved, cleared, denied, or otherwise disappeared from
server state.
Expected behavior:
If the displayed permission request no longer exists on the server, the TUI should dismiss the dialog or resync permission state instead of leaving a modal that cannot
be confirmed.
Actual behavior:
The stale permission dialog remains visible and blocks the user. Enter confirm is a no-op.
Workaround:
Opening a fresh opencode attach window to the same server/session bypasses the stale TUI state.
Example workaround:
opencode attach http://127.0.0.1:9888/ --session <session_id> --dir <project_dir>
Possible cause:
This looks like a lifecycle/state reconciliation bug between permission events and the TUI overlay state. The TUI appears to keep rendering a permission request after / permission no longer contains it. Similar to #14301 in spirit, but this happens in the terminal TUI/tmux attach flow rather than an ACP client.
Suggested fix:
On permission confirm, focus/resume, or attach, the TUI should refetch/reconcile pending permissions from the server. If the currently displayed permission ID is missing
from /permission, close the overlay and refresh UI state.
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
github-actions commentedon May 19, 2026
This issue might be a duplicate of or related to existing issues. Please check:
permission.askedevents during project-lookup race → tool hangs forever → OOM #27879: TUI silently dropspermission.askedevents during project-lookup race — also describes TUI permission state becoming inconsistent with server state, with a suggestion to seed pending permissions from/permissionon bootstrap/attach (fix B in that issue would also address the stale overlay scenario described here)ztobs commentedon Jun 5, 2026
Also affected on Linux:
Operating System: Ubuntu 26.04 LTS (Resolute Raccoon)
Kernel: Linux 7.0.0-22-generic x86_64
Desktop: GNOME (Wayland)
Terminal: GNOME Terminal (xterm-256color)
Shell: zsh
Node: v23.1.0
OpenCode version: v1.15.12 through v1.16.0
Same symptoms — permission dialog options (
Allow once,Allow always,Reject) cannot be selected using either keyboard or mouse. Also affectsEscto cancel/stop actions. Not limited to Windows.poldon commentedon Jun 11, 2026
I'm seeing the same issue using the VS Code extension on Linux.
github-actions commentedon Aug 10, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.