You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Permission dialog approve button pushed off-screen and unclickable when shell command content is too long #40968
In the OpenCode desktop app, when a permission/confirmation dialog is shown for a shell command (运行 shell 命令 / "Run shell command"), the full command text is rendered as the dialog body. If the command is long (e.g. a git commit with a large multi-line commit message via heredoc), the content overflows the dialog's visible area and the action buttons (approve/deny) are pushed entirely below the visible fold. The buttons cannot be seen and therefore cannot be clicked, making it impossible to approve or reject the permission request.
Additionally, the heredoc body of such commands appears to be rendered twice: once as part of the full command string (e.g. git commit -m "$(cat <<'EOF' ... EOF )") and again as a separate cat <<'EOF' ... block immediately after it, with no separator, identical content, and no second "Permission Required" header. This duplication roughly doubles the dialog's content height for heredoc commands, which amplifies the overflow problem.
To Reproduce
In OpenCode desktop, trigger an action that requires shell command permission, such as a git add of many files followed by a git commit with a long multi-line -m "$(cat <<'EOF' ... EOF)" commit message.
The permission dialog appears showing the full command text.
Observe that the dialog body is taller than the visible area and no approve/deny buttons are visible.
Expected behavior
The approve/deny buttons should always remain visible and clickable, regardless of the length of the command content.
Ideally the buttons should be pinned/sticky at the bottom of the dialog, with the command text in a scrollable area above them (the scrollbar should only scroll the content, not the buttons).
Actual behavior
With long command content, the approve/deny buttons are rendered below the visible edge of the dialog and disappear entirely.
A scrollbar appears in the text area, but the buttons sit outside the scrollable viewport, so scrolling does not bring them into view. The permission request cannot be approved or denied.
For commands using heredocs (e.g. git commit -m "$(cat <<'EOF' ... EOF )"), the heredoc body is displayed twice — once inline in the full command and again as a standalone cat <<'EOF' ... block with identical content — making the dialog roughly twice as tall as the command text alone. This duplicated block also does not appear inside the scrollable area with the action buttons.
Screenshots
Screenshot of the permission dialog: title "需要权限 / Permission Required", description "运行 shell 命令 / Run shell command", the long git add ... git commit command text filling the whole dialog, and no action buttons visible at the bottom.
Environment
OpenCode desktop
macOS
OpenCode version: 1.18.13 (reproduced on 1.18.14 — the issue persists after updating to the latest version)
Still reproducible on the desktop app 2.0.23 (Electron, macOS arm64), so this does not appear resolved by the V2 desktop client either.
Reproduction (fresh, 2026-10-07)
An agent issues a shell command made of many ;-joined checks — not a heredoc, e.g. echo … ; ls … ; diff -q a b >/dev/null ; wc -l < f ; grep -rn ….
The permission prompt opens (it asks because one constituent is not allow-listed, e.g. diff).
In the desktop app the command body grows tall enough that the Allow/Reject buttons are pushed below the visible area and cannot be clicked or reached. The dialog does not scroll and cannot be resized to reveal them.
Impact
The pending request came from a scanner subagent. With no reachable button the subagent (and its parent run) stalled; it had to be unblocked out-of-band.
New details vs. the earlier reports
Triggers on a compound / multi-statement command whose parts are individually benign (echo, ls, diff, wc, grep) — not only on a long single line or a heredoc.
Reproduced on the desktop app (2.0.23), not just the TUI.
The blocked request belonged to a subagent, so a pipeline can stall silently with no visible way out.
Workaround (may be worth documenting)
A pending request can be answered through the server API:
GET /api/permission/request
POST /api/session/{sessionID}/permission/{requestID}/reply {"decision":"once"} # or "always" / "reject"
Related, closed as not planned: #40793 (TUI; includes a ScrollableText proposal), #29515, #30132.
Could bounding/wrapping the command body and keeping the action row fixed be reconsidered? Any sufficiently long command can hit this, and from inside the UI the user has no way to recover.
Activity
github-actions commentedon Aug 7, 2026
This issue might be a duplicate of an existing issue. Please check:
github-actions commentedon Oct 6, 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.
sek41frank commentedon Oct 6, 2026
Still reproducible on the desktop app 2.0.23 (Electron, macOS arm64), so this does not appear resolved by the V2 desktop client either.
Reproduction (fresh, 2026-10-07)
;-joined checks — not a heredoc, e.g.echo … ; ls … ; diff -q a b >/dev/null ; wc -l < f ; grep -rn ….diff).Impact
The pending request came from a
scannersubagent. With no reachable button the subagent (and its parent run) stalled; it had to be unblocked out-of-band.New details vs. the earlier reports
echo,ls,diff,wc,grep) — not only on a long single line or a heredoc.Workaround (may be worth documenting)
A pending request can be answered through the server API:
Environment
Related, closed as not planned: #40793 (TUI; includes a
ScrollableTextproposal), #29515, #30132.Could bounding/wrapping the command body and keeping the action row fixed be reconsidered? Any sufficiently long command can hit this, and from inside the UI the user has no way to recover.