anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[BUG] Autocomplete dropdown conflicts with permission dialog - visual overlap and keyboard event capture #3677

New Issue
Open
opened 2026-02-16 17:41:04 -05:00 by yindo · 4 comments
yindo commented 2026-02-16 17:41:04 -05:00
Owner
Copy Link
Copy Source

Originally created by @anntnzrb on GitHub (Dec 19, 2025).

Originally assigned to: @rekram1-node on GitHub.

Description

When the autocomplete dropdown (@ for files/agents or / for commands) is open and a permission request arrives (e.g., tool approval for bash/edit), there is a visual and functional conflict:

  1. Visual conflict: The autocomplete dropdown (zIndex={100}) visually overlaps and covers the permission options rendered inline in the messages area, making it impossible to see what permission is being requested.

  2. Keyboard conflict: Both components capture the same keys:

    • Autocomplete: escape, enter, tab, up, down
    • Permission dialog: enter (accept once), a (always), d (deny), escape (reject)

The autocomplete processes keyboard events first, so when both are active, the permission dialog cannot receive input correctly.

Steps to Reproduce

  1. Start typing a message with @ or / to open the autocomplete dropdown
  2. While the dropdown is open, have the LLM trigger a tool that requires permission (e.g., bash command, file edit)
  3. Observe that:
    • The permission request appears behind/under the autocomplete dropdown
    • Keyboard shortcuts for accepting/denying the permission don't work as expected

Alternate scenario:

  1. Have the LLM running and generating content
  2. Start typing @ or / to open autocomplete
  3. A permission request arrives mid-interaction
  4. Cannot see the permission options while autocomplete is open

Expected Behavior

When a permission request arrives:

  • The autocomplete should close automatically (since the prompt is disabled anyway when permissions().length > 0)
  • OR the permission UI should have higher visual priority (z-index)
  • Keyboard events should be routed to the permission handler, not the autocomplete

Actual Behavior

  • The autocomplete remains visible and covers the permission options
  • Keyboard events are captured by the autocomplete, preventing permission responses
  • User must manually dismiss autocomplete (if possible) to interact with permissions

Technical Analysis

Relevant code locations:

  • packages/opencode/src/cli/cmd/tui/component/prompt/autocomplete.tsx:420-439 - Autocomplete has zIndex={100} and no logic to close when permissions arrive
  • packages/opencode/src/cli/cmd/tui/routes/session/index.tsx:197-218 - Permission keyboard handler checks for dialogs but not autocomplete state
  • packages/opencode/src/cli/cmd/tui/routes/session/index.tsx:1001 - Prompt is disabled when permissions pending, but autocomplete isn't notified
  • packages/opencode/src/cli/cmd/tui/component/prompt/index.tsx:764 - Autocomplete processes onKeyDown before other handlers

Proposed Solution

The simplest fix would be to close the autocomplete when permissions are pending:

  1. Pass a disabled or hidden prop to Autocomplete component
  2. When permissions().length > 0, set this prop to true
  3. In Autocomplete, call hide() when this prop becomes true

This aligns with the existing behavior where the prompt is already disabled during permission requests.

OpenCode version

Latest

Operating System

Any

Terminal

Any

Originally created by @anntnzrb on GitHub (Dec 19, 2025). Originally assigned to: @rekram1-node on GitHub. ### Description When the autocomplete dropdown (`@` for files/agents or `/` for commands) is open and a permission request arrives (e.g., tool approval for bash/edit), there is a visual and functional conflict: 1. **Visual conflict**: The autocomplete dropdown (`zIndex={100}`) visually overlaps and covers the permission options rendered inline in the messages area, making it impossible to see what permission is being requested. 2. **Keyboard conflict**: Both components capture the same keys: - Autocomplete: `escape`, `enter`, `tab`, `up`, `down` - Permission dialog: `enter` (accept once), `a` (always), `d` (deny), `escape` (reject) The autocomplete processes keyboard events first, so when both are active, the permission dialog cannot receive input correctly. ### Steps to Reproduce 1. Start typing a message with `@` or `/` to open the autocomplete dropdown 2. While the dropdown is open, have the LLM trigger a tool that requires permission (e.g., bash command, file edit) 3. Observe that: - The permission request appears behind/under the autocomplete dropdown - Keyboard shortcuts for accepting/denying the permission don't work as expected **Alternate scenario:** 1. Have the LLM running and generating content 2. Start typing `@` or `/` to open autocomplete 3. A permission request arrives mid-interaction 4. Cannot see the permission options while autocomplete is open ### Expected Behavior When a permission request arrives: - The autocomplete should close automatically (since the prompt is disabled anyway when `permissions().length > 0`) - OR the permission UI should have higher visual priority (z-index) - Keyboard events should be routed to the permission handler, not the autocomplete ### Actual Behavior - The autocomplete remains visible and covers the permission options - Keyboard events are captured by the autocomplete, preventing permission responses - User must manually dismiss autocomplete (if possible) to interact with permissions ### Technical Analysis **Relevant code locations:** - `packages/opencode/src/cli/cmd/tui/component/prompt/autocomplete.tsx:420-439` - Autocomplete has `zIndex={100}` and no logic to close when permissions arrive - `packages/opencode/src/cli/cmd/tui/routes/session/index.tsx:197-218` - Permission keyboard handler checks for dialogs but not autocomplete state - `packages/opencode/src/cli/cmd/tui/routes/session/index.tsx:1001` - Prompt is disabled when permissions pending, but autocomplete isn't notified - `packages/opencode/src/cli/cmd/tui/component/prompt/index.tsx:764` - Autocomplete processes `onKeyDown` before other handlers ### Proposed Solution The simplest fix would be to close the autocomplete when permissions are pending: 1. Pass a `disabled` or `hidden` prop to `Autocomplete` component 2. When `permissions().length > 0`, set this prop to `true` 3. In `Autocomplete`, call `hide()` when this prop becomes `true` This aligns with the existing behavior where the prompt is already disabled during permission requests. ### OpenCode version Latest ### Operating System Any ### Terminal Any
yindo added the opentui label 2026-02-16 17:41:04 -05:00
yindo commented 2026-02-16 17:41:05 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 19, 2025):

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

  • #3455: [FEATURE]: Make permissions dialog non-blocking and add modifier key shortcuts - Addresses keyboard conflicts with permissions dialog
  • #4934: Scrolling induces permission rejection - Related to permissions dialog interaction issues
  • #4092: [FEATURE]: better navigation of output, alternative vim mode and non-blocking agent permission requests - Discusses non-blocking permissions dialog to prevent keyboard event conflicts

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Dec 19, 2025): This issue might be a duplicate of existing issues. Please check: - #3455: [FEATURE]: Make permissions dialog non-blocking and add modifier key shortcuts - Addresses keyboard conflicts with permissions dialog - #4934: Scrolling induces permission rejection - Related to permissions dialog interaction issues - #4092: [FEATURE]: better navigation of output, alternative vim mode and non-blocking agent permission requests - Discusses non-blocking permissions dialog to prevent keyboard event conflicts Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:41:05 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 19, 2025):

Dax is reworking permissions stuff inclduing UI, this shoudl be fixed soon

@rekram1-node commented on GitHub (Dec 19, 2025): Dax is reworking permissions stuff inclduing UI, this shoudl be fixed soon
yindo commented 2026-02-16 17:41:05 -05:00
Author
Owner
Copy Link
Copy Source

@anntnzrb commented on GitHub (Dec 19, 2025):

Thanks for the quick response @rekram1-node! Good to know this is already being addressed in the permissions UI rework.

I'll keep an eye on the related issues (#3455, #4092) for updates. Feel free to close this if it's covered by the upcoming changes.

@anntnzrb commented on GitHub (Dec 19, 2025): Thanks for the quick response @rekram1-node! Good to know this is already being addressed in the permissions UI rework. I'll keep an eye on the related issues (#3455, #4092) for updates. Feel free to close this if it's covered by the upcoming changes.
yindo commented 2026-02-16 17:41:05 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 20, 2025):

ill leave open and see once his changes land if this is still an issue or not

@rekram1-node commented on GitHub (Dec 20, 2025): ill leave open and see once his changes land if this is still an issue or not
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#3677
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?