anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Accept all behavior for bash chains #2670

New Issue
Open
opened 2026-02-16 17:36:43 -05:00 by yindo · 18 comments
yindo commented 2026-02-16 17:36:43 -05:00
Owner
Copy Link
Copy Source

Originally created by @igordertigor on GitHub (Nov 7, 2025).

Originally assigned to: @igordertigor on GitHub.

Question

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

  1. Accept once (Enter)
  2. Accept always (a)
  3. 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.

Originally created by @igordertigor on GitHub (Nov 7, 2025). Originally assigned to: @igordertigor on GitHub. ### Question When an agent wants to run a back command, it asks for permission. There are three options: 1. Accept once (Enter) 2. Accept always (a) 3. Reject (Esc) Although 1 and 3 are pretty clear, I find it difficult to understand what 2 actually means. The [documentation on permissions](https://opencode.ai/docs/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.
yindo added the documentation label 2026-02-16 17:36:43 -05:00
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 7, 2025):

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

  • #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
  • #1813: Discusses auto-accept/yolo mode switching, which relates to understanding permission scopes and behaviors
  • #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.

@github-actions[bot] commented on GitHub (Nov 7, 2025): This issue might be a duplicate of existing issues. Please check: - #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 - #1813: Discusses auto-accept/yolo mode switching, which relates to understanding permission scopes and behaviors - #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.
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

@igordertigor commented on GitHub (Nov 7, 2025):

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

@igordertigor commented on GitHub (Nov 7, 2025): This is about missing documentation, not about the accept always behavior itself. Hence the above github-actions comments do not apply.
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

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

@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

@rekram1-node commented on GitHub (Nov 7, 2025): @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
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

@igordertigor commented on GitHub (Nov 10, 2025):

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

@igordertigor commented on GitHub (Nov 10, 2025): Thank you! That's very useful. Will that become part of the documentation at some point?
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

@igordertigor commented on GitHub (Nov 10, 2025):

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

@igordertigor commented on GitHub (Nov 10, 2025): I'm happy to add it if you need help.
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 10, 2025):

that would be amazing actually thank u @igordertigor

@rekram1-node commented on GitHub (Nov 10, 2025): that would be amazing actually thank u @igordertigor
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

@igordertigor commented on GitHub (Nov 20, 2025):

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

@igordertigor commented on GitHub (Nov 20, 2025): @rekram1-node can you give me a pointer where to find the documentation code?
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 20, 2025):

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 commented on GitHub (Nov 20, 2025): 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
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

@igordertigor commented on GitHub (Dec 10, 2025):

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 commented on GitHub (Dec 10, 2025): 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.
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

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

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 commented on GitHub (Dec 29, 2025): 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`
yindo commented 2026-02-16 17:36:44 -05:00
Author
Owner
Copy Link
Copy Source

@igordertigor commented on GitHub (Dec 30, 2025):

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

  1. 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?
  2. 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.
  3. 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.
@igordertigor commented on GitHub (Dec 30, 2025): @aspiers those are very good points and I've been thinking about this too. So here are some of my thoughts: 1. 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? 2. 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. 3. 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.
yindo commented 2026-02-16 17:36:45 -05:00
Author
Owner
Copy Link
Copy Source

@colinmollenhour commented on GitHub (Dec 31, 2025):

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:

Image

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

@colinmollenhour commented on GitHub (Dec 31, 2025): 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: <img width="1960" height="837" alt="Image" src="https://github.com/user-attachments/assets/f0ef6eb2-41e8-4fd1-95f2-0c21b6b2302b" /> 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).
yindo commented 2026-02-16 17:36:45 -05:00
Author
Owner
Copy Link
Copy Source

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

This is gonna be fixed soon

@rekram1-node commented on GitHub (Dec 31, 2025): This is gonna be fixed soon
yindo commented 2026-02-16 17:36:45 -05:00
Author
Owner
Copy Link
Copy Source

@aspiers commented on GitHub (Jan 5, 2026):

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

@aspiers commented on GitHub (Jan 5, 2026): @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](https://github.com/anomalyco/opencode/issues/4041#issuecomment-3697822490), 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](https://github.com/anomalyco/opencode/blob/dev/packages/opencode/src/permission/arity.ts). 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.)
yindo commented 2026-02-16 17:36:45 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Jan 5, 2026):

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 commented on GitHub (Jan 5, 2026): 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
yindo commented 2026-02-16 17:36:45 -05:00
Author
Owner
Copy Link
Copy Source

@aspiers commented on GitHub (Jan 5, 2026):

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

@aspiers commented on GitHub (Jan 5, 2026): @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.
yindo commented 2026-02-16 17:36:45 -05:00
Author
Owner
Copy Link
Copy Source

@aspiers commented on GitHub (Jan 6, 2026):

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

Image

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 commented on GitHub (Jan 6, 2026): BTW I just experienced a perfect real-world example of why it's so important to allow the user to edit the command pattern: <img width="1507" height="555" alt="Image" src="https://github.com/user-attachments/assets/fcca82a8-78cb-43e2-b307-5fafd545e1b9" /> 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.
yindo commented 2026-02-16 17:36:45 -05:00
Author
Owner
Copy Link
Copy Source

@igordertigor commented on GitHub (Jan 9, 2026):

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".
@igordertigor commented on GitHub (Jan 9, 2026): 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".
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label documentation
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2670
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?