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

[FEATURE]: Safer default for build agent: prompt on destructive bash commands #7344

New Issue
Open
opened 2026-02-16 18:06:54 -05:00 by yindo · 4 comments
yindo commented 2026-02-16 18:06:54 -05:00
Owner
Copy Link
Copy Source

Originally created by @Silent-Crafter on GitHub (Jan 23, 2026).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Current behavior

The build agent currently allows any and every bash command to run without user confirmation by default. This behavior is documented and also the out-of-the-box experience for new users.

Why this is risky

LLMs can occasionally hallucinate or generate malformed shell commands. For destructive commands, even a small formatting mistake can have irreversible consequences.

Example:
An LLM can execute the following command

rm -rf ~/ testfolder

instead of

rm -rf ~/testfolder

Due to this single space character token, a user's entire home directory (or any other intermediate directory) will be nuked without any warning whatsoever.

This issue especially affects new users eager to try out the tool. New users will often try the tool before reviewing permission configuration. A single hallucinated command can permanently damage a system.

Proposed improvement

Keep the current permissive defaults for non-destructive commands, but change the default behavior for a small set of known destructive commands to require confirmation (ask), for example:

  • rm
  • rmdir

This would:

  • Significantly reduce foot-gun risk
  • Protect new users
  • Preserve flexibility for advanced users who explicitly customize permissions.
  • the proposed behaviour acts like an opt-out behaviour, so power users who willing modify the permissions are themselves responsible for any consequences.

Scope

  • Specifically for the build agent and the explore agent
  • Does not affect users who explicitly override permissions in configuration

Existing Related Issues

From the issues I have reviewed:

  • Many talk about permissions being too permissive with respect to all bash commands in general.
  • Some talk about permission enforcement bugs.
  • Some complain about unsafe defaults, again, with respect to all bash commands in general.

But none clearly focus on this specific aspect of only preventing unauthorized execution of destructive bash commands. This issue stays faithful to original idea for the build and explore agents while only restricting a part of the implementation to provide more safe and secure out-of-the-box experience.

If this direction sounds reasonable, I’m happy to follow up with a PR where i have already addressed the issue in my fork.

Originally created by @Silent-Crafter on GitHub (Jan 23, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request ### Current behavior The build agent currently allows any and every bash command to run without user confirmation by default. This behavior is documented and also the out-of-the-box experience for new users. ### Why this is risky LLMs can occasionally hallucinate or generate malformed shell commands. For destructive commands, even a small formatting mistake can have irreversible consequences. Example: An LLM can execute the following command ```bash rm -rf ~/ testfolder ``` instead of ```bash rm -rf ~/testfolder ``` Due to this single space character token, a user's entire home directory (or any other intermediate directory) will be nuked without any warning whatsoever. This issue especially affects new users eager to try out the tool. New users will often try the tool before reviewing permission configuration. A single hallucinated command can permanently damage a system. ### Proposed improvement Keep the current permissive defaults for non-destructive commands, but change the default behavior for a small set of known destructive commands to require confirmation (ask), for example: - `rm` - `rmdir` This would: - Significantly reduce foot-gun risk - Protect new users - Preserve flexibility for advanced users who explicitly customize permissions. - the proposed behaviour acts like an opt-out behaviour, so power users who willing modify the permissions are themselves responsible for any consequences. ### Scope - Specifically for the build agent and the explore agent - Does not affect users who explicitly override permissions in configuration ### Existing Related Issues From the issues I have reviewed: - Many talk about permissions being too permissive with respect to all bash commands in general. - Some talk about permission enforcement bugs. - Some complain about unsafe defaults, again, with respect to all bash commands in general. But none clearly focus on this specific aspect of only preventing unauthorized execution of destructive bash commands. This issue stays faithful to original idea for the build and explore agents while only restricting a part of the implementation to provide more safe and secure out-of-the-box experience. If this direction sounds reasonable, I’m happy to follow up with a PR where i have already addressed the issue in my fork.
yindo added the discussion label 2026-02-16 18:06:54 -05:00
yindo commented 2026-02-16 18:06:54 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 23, 2026):

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

  • #5076: [Security discussion] OpenCode should have better/safer defaults to be more security minded - focuses on overall security defaults including bash permissions
  • #7136: Config Flag to mark part of the global config as non-overridable per project - discusses making bash permissions non-overridable
  • #2206: [FEATURE] add exec tool as more secure alternative to bash tool - proposes safer command execution without shell
  • #6488: Bash Fork Issues - includes detailed analysis and recommendations for safer bash command handling
  • #7504: An agent is able to read all filesystem outside a project directory in Plan mode - discusses file system access safety

Your proposal specifically focuses on prompting for destructive commands (rm, rmdir) by default, which is a more targeted approach than the broader permission model changes discussed in these issues. This complements the security discussions while staying focused on this particular foot-gun scenario.

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

@github-actions[bot] commented on GitHub (Jan 23, 2026): This issue might be a duplicate of existing issues. Please check: - #5076: [Security discussion] OpenCode should have better/safer defaults to be more security minded - focuses on overall security defaults including bash permissions - #7136: Config Flag to mark part of the global config as non-overridable per project - discusses making bash permissions non-overridable - #2206: [FEATURE] add `exec` tool as more secure alternative to bash tool - proposes safer command execution without shell - #6488: Bash Fork Issues - includes detailed analysis and recommendations for safer bash command handling - #7504: An agent is able to read all filesystem outside a project directory in Plan mode - discusses file system access safety Your proposal specifically focuses on prompting for destructive commands (`rm`, `rmdir`) by default, which is a more targeted approach than the broader permission model changes discussed in these issues. This complements the security discussions while staying focused on this particular foot-gun scenario. Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 18:06:54 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Jan 23, 2026):

You can set the permissions up to achieve this in your own configuration file. Use something like this:

"permission": {
    "bash": {
      "rm -rf*": "ask",
      "*": "allow",
    },
  },

Then running any rm -rf command will require that you confirm permission to run the command, while running anything other command will be allowed.

@ariane-emory commented on GitHub (Jan 23, 2026): You can set the permissions up to achieve this in your own configuration file. Use something like this: ```json "permission": { "bash": { "rm -rf*": "ask", "*": "allow", }, }, ``` Then running any `rm -rf` command will require that you confirm permission to run the command, while running anything other command will be allowed.
yindo commented 2026-02-16 18:06:55 -05:00
Author
Owner
Copy Link
Copy Source

@Silent-Crafter commented on GitHub (Jan 24, 2026):

@ariane-emory You clearly didn't get my point. Please read the Proposed Improvement and Scope section properly.

What i am mean to say here is, new users who are eager to try out the tool, won't get into permissions and configuration right off the bat. And the default build agent allows every command to be run without permission.

Whether users know this or not about build agent, LLMs can and will sometimes, execute improper commands like i have mentioned in my issue. Whether it be hallucination or improper formatting, this is outside of the user's and opencode's control. These things can happen to anyone, inclluding me and you, albeit rarely.

The main reason I am proposing this change is to protect new users from this. By making this improvement, we make this behavior as opt-out, which will improve the overall user-friendliness, safety and security of the tool out-of-the-box.

There onwards, if the user wishes to, they can modify the permissions as per their will through the configuration file. Any incident after this will be the responsibility of the user.

Again, this proposed feature is meant to improve the out-of-the-box experience the tool provides. Its only going to provide safer and secure permissions by default.

@Silent-Crafter commented on GitHub (Jan 24, 2026): @ariane-emory You clearly didn't get my point. Please read the Proposed Improvement and Scope section properly. What i am mean to say here is, **new users** who are eager to try out the tool, **won't** get into permissions and configuration right off the bat. And the default build agent allows every command to be run without permission. Whether users know this or not about build agent, LLMs can and will sometimes, execute improper commands like i have mentioned in my issue. Whether it be hallucination or improper formatting, this is outside of the user's and opencode's control. These things can happen to anyone, inclluding me and you, albeit rarely. The main reason I am proposing this change is to **protect new users** from this. By making this improvement, we make this behavior as opt-out, which will improve the overall user-friendliness, safety and security of the tool out-of-the-box. There onwards, if the user wishes to, they can modify the permissions as per their will through the configuration file. Any incident after this will be the responsibility of the user. Again, this proposed feature is meant to **improve the out-of-the-box experience the tool provides.** Its only going to provide safer and secure permissions by default.
yindo commented 2026-02-16 18:06:55 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Jan 24, 2026):

@Silent-Crafter I've carefully re-read your initial post, but I don't feel like I've gleaned anything new upon review that I hadn't grasped the first time around, and I'm sorry to say that my own opinion differs. However, diverse opinions are one of the things that contribute to making projects like this one so great, so I shan't chime in with my own and wish you the best of luck in promoting your own. Cheers. ;)

@ariane-emory commented on GitHub (Jan 24, 2026): @Silent-Crafter I've carefully re-read your initial post, but I don't feel like I've gleaned anything new upon review that I hadn't grasped the first time around, and I'm sorry to say that my own opinion differs. However, diverse opinions are one of the things that contribute to making projects like this one so great, so I shan't chime in with my own and wish you the best of luck in promoting your own. Cheers. ;)
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 discussion
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#7344
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?