Skip to content

Permission dialog approve button pushed off-screen and unclickable when shell command content is too long #40968

Closed as not planned

Description

@WHAT-BUG

Describe the bug

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

  1. 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.
  2. The permission dialog appears showing the full command text.
  3. 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.

Image

Environment

  • OpenCode desktop
  • macOS
  • OpenCode version: 1.18.13 (reproduced on 1.18.14 — the issue persists after updating to the latest version)

Activity

  1. github-actions commented on Aug 7, 2026

    @github-actions
    Contributor

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

  2. github-actions commented on Oct 6, 2026

    @github-actions
    Contributor

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

  3. sek41frank commented on Oct 6, 2026

    @sek41frank

    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)

    1. 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 ….
    2. The permission prompt opens (it asks because one constituent is not allow-listed, e.g. diff).
    3. 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"
    

    Environment

    • opencode version: 2.0.23 (desktop app, Electron; auto-update channel)
    • OS: macOS Darwin 25.4.0 / arm64
    • Shell: /bin/zsh
    • Active plugins: none

    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.

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions