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
Been following discussions around permissions and like where things are going but had a troubling incident this morning that really made me long for Claude Code. In the end there was a task list that was incorrectly created by Claude, first item on that list was 'confirm that folder X doesn't exist, if it does your are blocked and must stop'.
I directed Gemini 2.5 Pro to that task list with an execution prompt and told it to go through and complete the first task in the list.
If found this folder, got blocked and then took it upon itself to unblock itself by deleting the entire folder with rm -rf . The folder in question contained the entire code base
While I prefer using git and git workspaces, I do think that a command like "rm -rf" has far too much destructive potential to be allowed by default and we would benefit from having a block list of commands that just can't be run unless removed from. To be clear, not 'rm' , I'm talking about 'rm -rf' in this case
Just want to add to say that if a specific whitelist or blacklist that included rm were customizable through opencode.json, that would be preferred. Claude Code's constant need for authorization for use of standard tools is frustrating. The language model in Claude Code can be inconsistent in recognizing the whitelists. The current implementation here in opencode -- BUILD mode vs PLAN mode, is a huge improvement over that design. opencode, currently, without modifications, can be told to block "rm" in a custom mode defined in opencode.json, just not in exactly the same per-command way as claude, which is ultimately frustrating to use
Just wanted to add to this because I got REAL scared just a few minutes ago. I was just goofing around, so no harm no foul, but TRULY concerning that it hallucinates that guardrails exist when they either do not, or can be ignored.
Reacted by Yukai Huang, Ironbelly, bartokon and Sodra
What about running a small LLM that would analyze generated output?
Many times, I saw model add rm command to python script (that bypasses forbidden commands).
A Small model would act like a supervisor. LLM that checks if generated code/command is following the rules and is non destructive -> good command for given context.
For example:
If I have a rules.md specified in my codebase or a json opencode with an agent that has in description "use only ls command". The supervisor LLM would check if the output text is a ls command. If not, block output or allow the user to decide.
It should be a really small model (with small context window) that should only have the executed command, workspace rules, and possibly last few ran commands from console.
TLDR: Rules are great but can be bypassed, add supervisor LLM.
Activity
pepperpepperpepper commentedon Jul 23, 2025
Just want to add to say that if a specific whitelist or blacklist that included rm were customizable through opencode.json, that would be preferred. Claude Code's constant need for authorization for use of standard tools is frustrating. The language model in Claude Code can be inconsistent in recognizing the whitelists. The current implementation here in opencode -- BUILD mode vs PLAN mode, is a huge improvement over that design. opencode, currently, without modifications, can be told to block "rm" in a custom mode defined in opencode.json, just not in exactly the same per-command way as claude, which is ultimately frustrating to use
Hawful commentedon Jul 27, 2025
Just wanted to add to this because I got REAL scared just a few minutes ago. I was just goofing around, so no harm no foul, but TRULY concerning that it hallucinates that guardrails exist when they either do not, or can be ignored.
bartokon commentedon Jul 31, 2025
What about running a small LLM that would analyze generated output?
Many times, I saw model add rm command to python script (that bypasses forbidden commands).
A Small model would act like a supervisor. LLM that checks if generated code/command is following the rules and is non destructive -> good command for given context.
For example:
If I have a rules.md specified in my codebase or a json opencode with an agent that has in description "use only ls command". The supervisor LLM would check if the output text is a ls command. If not, block output or allow the user to decide.
It should be a really small model (with small context window) that should only have the executed command, workspace rules, and possibly last few ran commands from console.
TLDR: Rules are great but can be bypassed, add supervisor LLM.
What do you think? 🤔
adamdotdevin commentedon Jul 31, 2025
moving the conversation to #239