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

More explicit bash command permissions #3447

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

Originally created by @dmitryrn on GitHub (Dec 10, 2025).

Originally assigned to: @rekram1-node on GitHub.

Description

Currently when you disallow all commands but one, opencode will be able run that command that has (almost?) anything after it. For example, I set * to ask, and cargo check to allow, and it can run cargo check > ~/.zshrc, which would override .zshrc, which is dangerous.

my config:

{
  "$schema": "https://opencode.ai/config.json",
  "autoupdate": "notify",
  "permission": {
    "edit": "ask",
    "bash": {
      "*": "ask",
      "cargo check": "allow"
    },
    "webfetch": "ask",
    "doom_loop": "ask",
    "external_directory": "ask"
  }
}

I did notice that if it cannot run cargo check; ls, so I assume there is some best-effort command parsing.

As far as I understand it has implicit wildcard in the end of specified command, which I think is not secure.

I think a better solution would be to allow only cargo check when "cargo check" is specified. And if a user wants flags, then they would either specify flags that they want, or "cargo check*" which would allow anything after cargo check

OpenCode version

1.0.143

Steps to reproduce

  1. have "bash": {"*": "ask","cargo check": "allow"} in config
  2. create a file test.txt, with abc in it
  3. open opencode and ask it: run "cargo check > ~/test.txt" and nothing else
  4. see that content in test.txt was overridden

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

Originally created by @dmitryrn on GitHub (Dec 10, 2025). Originally assigned to: @rekram1-node on GitHub. ### Description Currently when you disallow all commands but one, opencode will be able run that command that has (almost?) anything after it. For example, I set `*` to `ask`, and `cargo check` to `allow`, and it can run `cargo check > ~/.zshrc`, which would override `.zshrc`, which is dangerous. my config: ```json { "$schema": "https://opencode.ai/config.json", "autoupdate": "notify", "permission": { "edit": "ask", "bash": { "*": "ask", "cargo check": "allow" }, "webfetch": "ask", "doom_loop": "ask", "external_directory": "ask" } } ``` I did notice that if it cannot run `cargo check; ls`, so I assume there is some best-effort command parsing. As far as I understand it has implicit wildcard in the end of specified command, which I think is not secure. I think a better solution would be to allow **only** `cargo check` when `"cargo check"` is specified. And if a user wants flags, then they would either specify flags that they want, or `"cargo check*"` which would allow anything after `cargo check` ### OpenCode version 1.0.143 ### Steps to reproduce 1. have `"bash": {"*": "ask","cargo check": "allow"}` in config 2. create a file `test.txt`, with `abc` in it 3. open opencode and ask it: `run "cargo check > ~/test.txt" and nothing else` 4. see that content in test.txt was overridden ### Screenshot and/or share link _No response_ ### Operating System _No response_ ### Terminal _No response_
yindo added the bug label 2026-02-16 17:40:06 -05:00
yindo closed this issue 2026-02-16 17:40:06 -05:00
yindo commented 2026-02-16 17:40:06 -05:00
Author
Owner
Copy Link
Copy Source

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

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

  • #5310: Shell mode (! command) doesn't work on Windows - related to bash command execution and platform-specific handling

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

@github-actions[bot] commented on GitHub (Dec 10, 2025): This issue might be a duplicate of existing issues. Please check: - #5310: Shell mode (! command) doesn't work on Windows - related to bash command execution and platform-specific handling Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:40:06 -05:00
Author
Owner
Copy Link
Copy Source

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

yeah i think the flag part is a bug.

We use treesitter to parse commands & flags so it can catch the subcommands.

I think the redirects are a little annoying to catch tho

@rekram1-node commented on GitHub (Dec 10, 2025): yeah i think the flag part is a bug. We use treesitter to parse commands & flags so it can catch the subcommands. I think the redirects are a little annoying to catch tho
yindo commented 2026-02-16 17:40:06 -05:00
Author
Owner
Copy Link
Copy Source

@dmitryrn commented on GitHub (Dec 10, 2025):

I'm not sure how treesitter works, but is there a possibility that you will fix it to properly detect redirects with treesitter, but there is some other method of bypassing this system but you hasn't considered it?

@dmitryrn commented on GitHub (Dec 10, 2025): I'm not sure how treesitter works, but is there a possibility that you will fix it to properly detect redirects with treesitter, but there is some other method of bypassing this system but you hasn't considered it?
yindo commented 2026-02-16 17:40:06 -05:00
Author
Owner
Copy Link
Copy Source

@doodhout commented on GitHub (Dec 26, 2025):

I had a similar occurence of an LLM working around a permission restriction: write and edit were both set to deny, but it was still able to write to a file using the bash command cat "contents" > file.

I already notice that when a bash command contains piped commands, then each of the piped commands will need to have the permission "allowed" before it can continue without asking permission, however this does not seem to happen for stdout and stderr redirection to files. (i.e. >, >>, 2>, 2>>)

Would it be possible to 1. be able to detect output redirection (i.e. >, >>, 2>, 2>>), and 2. (allow users to) add an explicit permission for it to the permission tree? Perhaps two permissions, distinguishing between "redirecting from file to stdin" (e.g. cat < file) and "redirecting from stdout to file" (e.g. cat "contents" > file)

@doodhout commented on GitHub (Dec 26, 2025): I had a similar occurence of an LLM working around a permission restriction: write and edit were both set to deny, but it was still able to write to a file using the bash command `cat "contents" > file`. I already notice that when a bash command contains piped commands, then each of the piped commands will need to have the permission "allowed" before it can continue without asking permission, however this does not seem to happen for stdout and stderr redirection to files. (i.e. >, >>, 2>, 2>>) Would it be possible to 1. be able to detect output redirection (i.e. >, >>, 2>, 2>>), and 2. (allow users to) add an explicit permission for it to the permission tree? Perhaps two permissions, distinguishing between "redirecting from file to stdin" (e.g. `cat < file`) and "redirecting from stdout to file" (e.g. `cat "contents" > file`)
yindo commented 2026-02-16 17:40:07 -05:00
Author
Owner
Copy Link
Copy Source

@pschiel commented on GitHub (Jan 2, 2026):

redirected_statement in treesitter-bash are parents of the command nodes.

you can extract the command text with node.parent?.type === "redirected_statement" ? node.parent.text : node.text

and then use that one for the pattern matching.

@pschiel commented on GitHub (Jan 2, 2026): `redirected_statement` in treesitter-bash are parents of the command nodes. you can extract the command text with `node.parent?.type === "redirected_statement" ? node.parent.text : node.text` and then use that one for the pattern matching.
yindo commented 2026-02-16 17:40:07 -05:00
Author
Owner
Copy Link
Copy Source

@jpmelos commented on GitHub (Jan 24, 2026):

I just learned about this, and how is everyone not absolutely freaking out about this? 😅 Agents can literally write to any file that the current user has permission to write to, without having to ask for permission.

Image
@jpmelos commented on GitHub (Jan 24, 2026): I just learned about this, and how is everyone not absolutely freaking out about this? 😅 Agents can literally write to *any* file that the current user has permission to write to, without having to ask for permission. <img width="1508" height="1570" alt="Image" src="https://github.com/user-attachments/assets/b0887309-a77f-4fcd-97a8-3bb93c0bf820" />
yindo commented 2026-02-16 17:40:07 -05:00
Author
Owner
Copy Link
Copy Source

@pschiel commented on GitHub (Jan 25, 2026):

I just learned about this, and how is everyone not absolutely freaking out about this? 😅 Agents can literally write to any file that the current user has permission to write to, without having to ask for permission.

https://github.com/anomalyco/opencode/pull/6737 fixes this,

however there's a series of other commands you need to forbid too apart from > redirect,
e.g. printf + tee, dd, python etc, AI will find all the tricks when it wants to write something.

@pschiel commented on GitHub (Jan 25, 2026): > I just learned about this, and how is everyone not absolutely freaking out about this? 😅 Agents can literally write to _any_ file that the current user has permission to write to, without having to ask for permission. https://github.com/anomalyco/opencode/pull/6737 fixes this, however there's a series of other commands you need to forbid too apart from `>` redirect, e.g. `printf` + `tee`, `dd`, `python` etc, AI will find all the tricks when it wants to write something.
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 bug
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#3447
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?