Accept all behavior for bash chains

[igordertigor]

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.

[github-actions]

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.

[igordertigor]

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

[rekram1-node]

@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

[igordertigor]

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

[igordertigor]

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

[rekram1-node]

that would be amazing actually thank u @igordertigor

[igordertigor]

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

[rekram1-node]

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

[igordertigor]

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.

[aspiers]

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