You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. #1961, #2242, and #2206).
Nevertheless, I want to emphasize that the "permission" key in opencode.json often is not being fully respected.
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).
Let the context window grow a bit - e.g. ask the agent to edit some files.
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
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).
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. 😆
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.)
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).
Operating System
Distrobox with Debian GNU/Linux Sid on Vanilla OS 2.0 Orchid
Description
What happened?
The CLI correctly denies access, but the agent tries to find another way using
bash <command>, overwrites.envwith echo (instead of using write/edit tools), and conciously ignores restrictions specified in theAGENTS.mdfile.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. #1961, #2242, and #2206).
Nevertheless, I want to emphasize that the "permission" key in
opencode.jsonoften is not being fully respected.I already reported some related inconsistencies at #4287 (comment) and at #539 (comment) (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
git resetas 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 theAGENTS.md(even after explicitly asking to read them).Important
Screenshot and/or share link
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).
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. 😆(The last sentence comes from the agent but did not fit in the screenshot.)
Operating System
Distrobox with Debian GNU/Linux Sid on Vanilla OS 2.0 Orchid
Terminal
Guake 3.10