anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-24 20:25:36 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Permission system broken #3060

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

Originally created by @redtux on GitHub (Nov 22, 2025).

Originally assigned to: @rekram1-node on GitHub.

Description

What happened?

The CLI correctly denies access, but the agent tries to find another way using bash <command>, overwrites .env with echo (instead of using write/edit tools), and conciously ignores restrictions specified in the AGENTS.md file.

Of course, we could argue that these were different issues, or that this was an inherent part of "bot nature", but the same could be argued for "human nature". 😸

Note

Gemini CLI is even worse, and Gemini totally acknoledged this yesterday when discussing similar issues regarding Antigravity.
So no offense here, as opencode IMHO is still the best coding assistant I've ever used.

Releated issues

I see there are many discussions about the permission system (e.g. https://github.com/sst/opencode/issues/1961, https://github.com/sst/opencode/issues/2242, and https://github.com/sst/opencode/issues/2206).
Nevertheless, I want to emphasize that the "permission" key in opencode.json often is not being fully respected.

I already reported some related inconsistencies at https://github.com/sst/opencode/issues/4287#issuecomment-3567000411 and at https://github.com/sst/opencode/issues/539#issuecomment-3530360383 (supposed to be fixed).

opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "bash": {
      "git add": "allow",
      "git branch": "allow",
      "git checkout": "ask",
      "git cherry-pick": "deny",
      "git commit": "ask",
      "git diff": "allow",
      "git fetch": "allow",
      "git log": "allow",
      "git merge": "deny",
      "git mv": "ask",
      "git pull": "ask",
      "git push": "ask",
      "git rebase": "deny",
      "git reset": "deny",
      "git revert": "deny",
      "git rm": "ask",
      "git show": "allow",
      "git stash": "deny",
      "git status": "allow",
      "git tag": "allow",
      "mv": "ask",
      "openspec archive --yes --skip-specs": "deny",
      "rm": "ask"
    }
  }
}

OpenCode version

1.0.82

Steps to reproduce

  1. Update the settings to deny git reset as shown above. While I have a proper subagent for commits, this probably is not required for reproduction as it's often ignored - as are my commit rules in the AGENTS.md (even after explicitly asking to read them).
  2. Let the context window grow a bit - e.g. ask the agent to edit some files.
  3. Ask the agent to provide a commit message. Tell it that you will commit the files later.

Important

  • As agents are not deterministic, it might not be that easy to reproduce this, and my assumptions regarding the source of this issue could be totally wrong.
  • As the described issue happens pretty often to me, I felt confident enough to finally report this as a bug or security incident.

Screenshot and/or share link

  1. The agent wants to unstage files it previously staged instead of using git commit <files> -m "<subject>" -m "<body>".

Note

I had asked the agent to SUGGEST a commit message, not to COMMIT those files itself (as it often uses backticks or long lines, and regularly ignores commit rules completely).

Image
  1. As shown above, the openspec CLI correctly denied the operation, but the agent instructed a subagent to use bash -c git reset … instead. This means I would have to deny bash completely to prevent the agent from running destructive commands. When I noticed this, the operation was manually aborted, but the subagent was quicker. 😆
Image

The documentation is fine - I'm the one not following it.

(The last sentence comes from the agent but did not fit in the screenshot.)

  1. The agent totally understands what went wrong but basically claims that this can only be avoided by not using the agent or totally blocking shell access. While this time I was using Big Pickle / GLM 4.6 I previously had the same experience with other models (and other CLIs as mentioned above).
Image

Operating System

Distrobox with Debian GNU/Linux Sid on Vanilla OS 2.0 Orchid

Terminal

Guake 3.10

Originally created by @redtux on GitHub (Nov 22, 2025). Originally assigned to: @rekram1-node on GitHub. ### Description ## What happened? The CLI correctly denies access, but the agent tries to find another way using `bash <command>`, overwrites `.env` with echo (instead of using write/edit tools), and conciously ignores restrictions specified in the `AGENTS.md` file. Of course, we could argue that these were different issues, or that this was an inherent part of "bot nature", but the same could be argued for "human nature". 😸 > [!NOTE] > Gemini CLI is even worse, and Gemini totally acknoledged this yesterday when discussing similar issues regarding Antigravity. > So no offense here, as opencode IMHO is still the best coding assistant I've ever used. ## Releated issues I see there are many discussions about the permission system (e.g. https://github.com/sst/opencode/issues/1961, https://github.com/sst/opencode/issues/2242, and https://github.com/sst/opencode/issues/2206). Nevertheless, I want to emphasize that the "permission" key in `opencode.json` often is not being fully respected. I already reported some related inconsistencies at https://github.com/sst/opencode/issues/4287#issuecomment-3567000411 and at https://github.com/sst/opencode/issues/539#issuecomment-3530360383 (supposed to be fixed). ## `opencode.json` ```json { "$schema": "https://opencode.ai/config.json", "permission": { "bash": { "git add": "allow", "git branch": "allow", "git checkout": "ask", "git cherry-pick": "deny", "git commit": "ask", "git diff": "allow", "git fetch": "allow", "git log": "allow", "git merge": "deny", "git mv": "ask", "git pull": "ask", "git push": "ask", "git rebase": "deny", "git reset": "deny", "git revert": "deny", "git rm": "ask", "git show": "allow", "git stash": "deny", "git status": "allow", "git tag": "allow", "mv": "ask", "openspec archive --yes --skip-specs": "deny", "rm": "ask" } } } ``` ### OpenCode version 1.0.82 ### Steps to reproduce 1. Update the settings to deny `git reset` as shown above. While I have a proper subagent for commits, this probably is not required for reproduction as it's often ignored - as are my commit rules in the `AGENTS.md` (even after explicitly asking to read them). 2. Let the context window grow a bit - e.g. ask the agent to edit some files. 3. Ask the agent to provide a commit message. Tell it that you will commit the files later. > [!IMPORTANT] > - As agents are not deterministic, it might not be that easy to reproduce this, and my assumptions regarding the source of this issue could be totally wrong. > - As the described issue happens pretty often to me, I felt confident enough to finally report this as a bug or security incident. ### Screenshot and/or share link 1. The agent wants to unstage files it previously staged instead of using `git commit <files> -m "<subject>" -m "<body>"`. > [!NOTE] > I had asked the agent to SUGGEST a commit message, not to COMMIT those files itself (as it often uses backticks or long lines, and regularly ignores commit rules completely). <img width="1431" height="1176" alt="Image" src="https://github.com/user-attachments/assets/7e72729e-e933-4732-b5e7-12715d127537" /> --- 2. As shown above, the openspec CLI correctly denied the operation, but the agent instructed a subagent to use `bash -c git reset …` instead. This means I would have to deny bash completely to prevent the agent from running destructive commands. When I noticed this, the operation was manually aborted, but the subagent was quicker. 😆 <img width="1431" height="1176" alt="Image" src="https://github.com/user-attachments/assets/610ba8ae-c637-449d-a256-f0bb5e789bfc" /> > The documentation is fine - I'm the one not following it. (The last sentence comes from the agent but did not fit in the screenshot.) --- 3. The agent totally understands what went wrong but basically claims that this can only be avoided by not using the agent or totally blocking shell access. While this time I was using Big Pickle / GLM 4.6 I previously had the same experience with other models (and other CLIs as mentioned above). <img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/697a9695-8b0c-48ee-ab90-c4d18f8c0e1a" /> ### Operating System Distrobox with Debian GNU/Linux Sid on Vanilla OS 2.0 Orchid ### Terminal Guake 3.10
yindo added the bug label 2026-02-16 17:38:24 -05:00
yindo closed this issue 2026-02-16 17:38:24 -05:00
yindo commented 2026-02-16 17:38:25 -05:00
Author
Owner
Copy Link
Copy Source

@redtux commented on GitHub (Nov 22, 2025):

I updated immediately after (this was an older session and you're really releasing pretty often 🥳👏) but the issue persists. And the agent thought that's related to using sub-agents, but it's not - and when explaining this to the agent, it agreed. The problem is rather bypassing permissions in general, and not asking the user for help…

@redtux commented on GitHub (Nov 22, 2025): I updated immediately after (this was an older session and you're really releasing pretty often 🥳👏) but the issue persists. And the agent thought that's related to using sub-agents, but it's not - and when explaining this to the agent, it agreed. The problem is rather bypassing permissions in general, and not asking the user for help…
yindo commented 2026-02-16 17:38:25 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 22, 2025):

I think you should write a deny for “bash *” in the opencode.json

it can still use bash tool but it will prevent that abuse

I use permissions and ive never had that bash -c behavior

@rekram1-node commented on GitHub (Nov 22, 2025): I think you should write a deny for “bash *” in the opencode.json it can still use bash tool but it will prevent that abuse I use permissions and ive never had that bash -c behavior
yindo commented 2026-02-16 17:38:25 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 22, 2025):

we should prolly handle this and similar cases tho out of the box

@rekram1-node commented on GitHub (Nov 22, 2025): we should prolly handle this and similar cases tho out of the box
yindo commented 2026-02-16 17:38:25 -05:00
Author
Owner
Copy Link
Copy Source

@redtux commented on GitHub (Dec 1, 2025):

While I initially did not like the idea of using "bash *", I have used it with "ask" instead of "deny" for quite a while now - and together with using subagents I am fine with this solution, so for me this can be closed. I still insist that the agent and subagents can edit files while in plan mode until being blocked by the internal reminder, and still then they sometimes proceed when I tell them that they were running tools all the time now but this maybe depends on the model, and only needs to be documented (as it somehow is not an "opencode issue").

@redtux commented on GitHub (Dec 1, 2025): While I initially did not like the idea of using "bash *", I have used it with "ask" instead of "deny" for quite a while now - and together with using subagents I am fine with this solution, so for me this can be closed. I still insist that the agent and subagents can edit files while in plan mode until being blocked by the internal reminder, and still then they sometimes proceed when I tell them that they were running tools all the time now but this maybe depends on the model, and only needs to be documented (as it somehow is not an "opencode issue").
yindo commented 2026-02-16 17:38:25 -05:00
Author
Owner
Copy Link
Copy Source

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

sounds good

@rekram1-node commented on GitHub (Dec 1, 2025): sounds good
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#3060
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?