anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Command safety #485

New Issue
Closed
opened 2026-02-16 17:27:02 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 17:27:02 -05:00
Owner
Copy Link
Copy Source

Originally created by @ztomas-codes on GitHub (Jul 4, 2025).

Originally assigned to: @adamdotdevin on GitHub.

Feature Request: Command Safety - Confirmation for Automated Commands

I'm writing to request a new "command safety" feature within OpenCode. I've become increasingly apprehensive about commands that OpenCode executes automatically without explicit user confirmation.

The current behavior, where commands are run instantly without a prompt, feels risky. There's a significant potential for unintended or even destructive actions if a user isn't fully aware of what's about to be executed or if there's a slight misinterpretation of a prompt.

I propose implementing a "command safety" feature that would:

  • Require user confirmation: Before any command (especially those that modify files, run external scripts, or have significant system impact) is executed automatically, OpenCode should present a clear confirmation dialog.
  • Display the command clearly: This dialog should prominently display the exact command(s) that are about to be run. This transparency is crucial for users to understand and verify the action.
  • Offer "Approve" and "Cancel" options: Users should have the option to either Approve the execution, allowing the command to proceed, or Cancel it, preventing it from running.
Originally created by @ztomas-codes on GitHub (Jul 4, 2025). Originally assigned to: @adamdotdevin on GitHub. ## Feature Request: Command Safety - Confirmation for Automated Commands I'm writing to request a new **"command safety"** feature within OpenCode. I've become increasingly apprehensive about commands that OpenCode executes automatically without explicit user confirmation. The current behavior, where commands are run instantly without a prompt, feels risky. There's a significant potential for unintended or even destructive actions if a user isn't fully aware of what's about to be executed or if there's a slight misinterpretation of a prompt. I propose implementing a "command safety" feature that would: * **Require user confirmation:** Before any command (especially those that modify files, run external scripts, or have significant system impact) is executed automatically, OpenCode should present a clear confirmation dialog. * **Display the command clearly:** This dialog should prominently display the **exact command(s)** that are about to be run. This transparency is crucial for users to understand and verify the action. * **Offer "Approve" and "Cancel" options:** Users should have the option to either **Approve** the execution, allowing the command to proceed, or **Cancel** it, preventing it from running.
yindo closed this issue 2026-02-16 17:27:02 -05:00
yindo commented 2026-02-16 17:27:02 -05:00
Author
Owner
Copy Link
Copy Source

@alkeryn commented on GitHub (Jul 11, 2025):

@ztomas-codes i don't really care, that's why i run it in a lxc container or bubblewrap sandbox, don't give the tool access to thhings you don't want it to possibly access.

but if it remains an option why not, i personally prefer it disabled.

@alkeryn commented on GitHub (Jul 11, 2025): @ztomas-codes i don't really care, that's why i run it in a lxc container or bubblewrap sandbox, don't give the tool access to thhings you don't want it to possibly access. but if it remains an option why not, i personally prefer it disabled.
yindo commented 2026-02-16 17:27:02 -05:00
Author
Owner
Copy Link
Copy Source

@pbadeer commented on GitHub (Jul 26, 2025):

Real world example: I prompted to commit the changes and specifically called out which other file it should not include in the commit and said to only stage the files it worked on. Instead of using git add relevant-file.py to only stage the relevant files, it ran git checkout file-to-ignore.py first, then git add . and erased all pending changes to the outlier file that I told it to ignore.

@pbadeer commented on GitHub (Jul 26, 2025): Real world example: I prompted to commit the changes and specifically called out which other file it should not include in the commit and said to only stage the files it worked on. Instead of using `git add relevant-file.py` to only stage the relevant files, it ran `git checkout file-to-ignore.py` first, then `git add .` and erased all pending changes to the outlier file that I told it to ignore.
yindo commented 2026-02-16 17:27:02 -05:00
Author
Owner
Copy Link
Copy Source

@adamdotdevin commented on GitHub (Jul 31, 2025):

moving the conversation to #239

@adamdotdevin commented on GitHub (Jul 31, 2025): moving the conversation to #239
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
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#485
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?