Accept all behavior for bash chains

Question

When an agent wants to run a back command, it asks for permission. There are three options:

Accept once (Enter)
Accept always (a)
Reject (Esc)
Although 1 and 3 are pretty clear, I find it difficult to understand what 2 actually means. The documentation on permissions seems to focus more on configuration level permissions.

For a command like cd directory && ls -lh, what would "Accept always" actually accept? Is this for the entire chain, so that anything starting with cd directory is fine? Or is this for each component path, so that cd directory and ls -lh are fine? How would this generalize to new chains? After accepting cd directory && ls -lh and cd other_directory && rm -rf *, can the agent then also decide to run cd directory && rm -rf *? Without this kind of explanation it seems that the "Accept always" option is pretty limited.

This issue might be a duplicate of existing issues. Please check:

[FEATURE]:Add "Accept for Session" Option for Permission Prompts #3419: Requests an "Accept for Session" option to address confusion around the "always" permission scope - very similar to your question about what "Accept always" actually means
Feature Request: Yolo and non-Yolo mode (auto-accept) #1813: Discusses auto-accept/yolo mode switching, which relates to understanding permission scopes and behaviors
Feature Request: Add Prefix Requirements for Permission Prompts #2521: Discusses safety concerns with the current "accept always" system and proposes improvements to make permission behavior clearer

Feel free to ignore if none of these address your specific case.

This is about missing documentation, not about the accept always behavior itself. Hence the above github-actions comments do not apply.

@igordertigor

@igordertigor we use tree sitter to parse out the commands so accept always would whitelist:

"cd *"
"ls *"

In the event of something like:

"git log"

an always approve would whitelist "git log *"

but it wouldn't whitelist "git commit ...." etc

Thank you! That's very useful. Will that become part of the documentation at some point?

I'm happy to add it if you need help.

@igordertigor

that would be amazing actually thank u @igordertigor

@rekram1-node

@rekram1-node can you give me a pointer where to find the documentation code?

Yes, all docs are in packages/web/

You can look for .mdx files in particular

You can run the docs locally:

bun i
cd packages/web
bun run dev

then visit url in ur browser

@rekram1-node

There is now a pull request for my documentation changes at #5340 . When writing this down, I noticed that I actually might not have fully understood your answer, @rekram1-node . So, I guess this is to some extent also a validation that I understood everything correctly.

@igordertigor

While I'm a huge fan of documenting this properly (and thanks a lot for @igordertigor helping out there!), I really think we can and should do better here. We can reduce the need for the user to check the docs to understand option 2, simply by enhancing the text so that it tells the user:

exactly which command patterns it will accept, and
that this (only) applies for the rest of the session

Furthermore, there should be a fourth option which is like option 2 but persists for all future sessions by automatically modifying the config. For this, it probably makes sense to adopt an approach similar to Claude Code, which uses two config files per repo (and similarly per user):

.claude/settings.json - this is never automatically modified and typically checked into git
.claude/settings.local.json - this can be automatically modified and is typically not checked into git

@aspiers

@aspiers those are very good points and I've been thinking about this too. So here are some of my thoughts:

I noticed that the accept-all behavior for file edits is also a little unclear. Does this apply to all future edits of the current file or all future edits in general? Or something in between?
Accept-all behavior: The current permissions (along with scope, "expiry", ...) could also be listed in the side panel on the right. This way users would have an overview of the permissions they gave so far. Once users have more transparency into what the current permissions are, one could also think about allowing on the fly modifications - most notably revoking permissions. I often would like to revoke permissions half way through a session. For example, after the main work was done but I want the agent to stay in the same context and document its work.
Settings files: I usually edit my config file as I go. I noticed one complication there: Should edits affect the current agent or all agents (i.e. edit the agent specific permissions table or the global one). I don't think there would be a general answer. This seems to really depend on the case.

Just adding another data point.. The term "all" is probably one that should be avoided without a qualifier. In Plan mode I often come back to find it stuck on waiting for permissions I thought I already gave it. For example, I've pressed "a" dozens of times but still got this multiple times in a row despite pressing "a" each time, only the commit SHAs and line number ranges differed each time:

That is, my expectation is that "git show" is read-only and "sed -n" is read-only so pressing "a" should apply to all uses of them but it seems to not be the case. Having an option to switch modes to yolo-equivalent mid-session would be ideal as I get that it's not at all obvious if a generated command is truly read-only, but I trust Opus not to clobber files in plan mode (or am willing to accept the risks).

This is gonna be fixed soon

@rekram1-node

@rekram1-node I submitted #6714 which is related in that it gives the user more clarity over exactly what permissions they are accepting. That said, in some cases I think there should be multiple options offered to the user:

Firstly, as mentioned above, there should be an option to persist the permission for all future sessions.

Secondly, if the command in question is gh issue list --repo anomalyco/opencode --search "Permission", the user might want to allow any of the following command wildcard patterns:

gh issue list --repo anomalyco/opencode --search *
gh issue list --repo anomalyco/opencode *
gh issue list --repo anomalyco/*
gh issue list *
gh issue *
gh *

Note that not all possible patterns make perfect sense to allow, e.g. if you wanted to allow gh issue list --repo *, why wouldn't you just allow gh issue list? And deciding which do or don't make sense is impossible because OpenCode would then have to understand what every single shell command in the universe does.

That said, OpenCode does an impressively good job of guessing the best wildcard pattern, using a combination of built-in knowledge and an AI prompt. But it won't always get it right.

Mockup of proposed solution

So I think it would be more helpful for OpenCode to err on the side of flexibility here rather than only letting you allow one fixed pattern or nothing at all. This could easily be achieved by giving the user the option to edit the command pattern so they can get exactly what they want. Here's a mockup of what it could look like:

|
| # Run a GitHub workflow
|
| $ gh workflow run unit-tests.yml
|
| Permission required to run this tool
|
| > 1. Allow just this once
|   2. Allow "gh workflow run" commands for the rest of this session
|   3. Allow "gh workflow run" commands for this and future sessions
|   4. Choose a different command pattern to allow
|   5. Don't allow any command
|
| Up/Down/Enter/1-6 to select, Esc to cancel
|

If the user selects 5, it could enter a very short wizard which shows something like:

|
| # Run a GitHub workflow
|
| $ gh workflow run unit-tests.yml
|
| Edit the command pattern you want to allow:
|
| $ gh workflow run unit-tests.yml*
|
| Enter to accept, Esc to cancel
|

Then after editing, they hit Enter and see something like:

|
| # Run a GitHub workflow
|
| $ gh workflow run unit-tests.yml
|
| Permission required to run this tool
|
|   1. Allow just this once, forgetting the command pattern
| > 2. Allow "gh workflow run *-tests.yml" commands for the rest of this session
|   3. Allow "gh workflow run *-tests.yml" commands for this and future sessions
|   4. Go back to editing the command pattern
|   5. Don't allow any command
|
| Up/Down/Enter/1-5 to select, Esc to cancel
|

(N.B. Here I am assuming that wildcards are allowed inside the pattern, not just at the end, although I don't know if that's actually supported yet. But it's just to demonstrate the point that the user might want a less obvious command pattern than the one OpenCode suggests.)

We started persisting the permission approvals per project, idk if we want to present the user w/ 5 different options everytime but we wanna make it so you can view and edit previous approvals youve done

@rekram1-node

@rekram1-node Personally I would miss the "allow for the rest of this session but not beyond" functionality, even though persisting across sessions is generally more useful. Being able to view and edit in-app sounds great though!

IMHO the most important part is being really clear about what command pattern is being added to the allow-list. If this is not shown as part of the acceptance process then it could easily be dangerous, e.g. the user could accidentally allow gh pr * instead of gh pr list * without realising.

BTW I just experienced a perfect real-world example of why it's so important to allow the user to edit the command pattern:

I only wanted to allow bash -n for syntax checking but it defaulted to allowing any bash invocation which is extremely dangerous.

This is why I suggested having Choose a different command pattern to allow as one of the inline options.

@aspiers

Seems like there has been quite some interesting discussion going on since I last checked. Most of these are great ideas. I'm a little concerned with given permissions per project. I often want to allow certain things for the duration of a particular task but want to disallow them afterwards (e.g. don't build in the middle of editing). I also really like @aspiers idea to be able to edit the allowed command.
@rekram1-node , I understand your concern about overwhelming users with options for this temporary permission dialog. However, I don't think that justifies cutting relevant functionality. I could see different options here:

The ask permission could define the different choices.
There could be a "more" option in the dialog that shows the other options.
The new confirm dialog after "always allow" could have three options: "confirm", "edit", "cancel".

To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

Accept all behavior for bash chains #4041

Question

Mockup of proposed solution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Accept all behavior for bash chains #4041

Description

Question

Activity

github-actions commented on Nov 7, 2025

igordertigor commented on Nov 7, 2025

rekram1-node commented on Nov 7, 2025

igordertigor commented on Nov 10, 2025

igordertigor commented on Nov 10, 2025

rekram1-node commented on Nov 10, 2025

igordertigor commented on Nov 20, 2025

rekram1-node commented on Nov 20, 2025

igordertigor commented on Dec 10, 2025

aspiers commented on Dec 29, 2025

igordertigor commented on Dec 30, 2025

colinmollenhour commented on Dec 31, 2025

rekram1-node commented on Dec 31, 2025

aspiers commented on Jan 5, 2026

Mockup of proposed solution

rekram1-node commented on Jan 5, 2026

aspiers commented on Jan 5, 2026

aspiers commented on Jan 6, 2026

igordertigor commented on Jan 9, 2026

thdxr commented on Mar 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions