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 additional opencode attach http://127.0.0.1:9888/ ... panes
- Plugins:
- oh-my-openagent@4.2.2
- 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:
GET http://127.0.0.1:9888/permission
=> < />< />
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
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 --port 9888, with additionalopencode attach http://127.0.0.1:9888/ ...panesObserved 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:
GET http://127.0.0.1:9888/permission
=> < />< />
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 attachwindow 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
/ permissionno 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