Compound-command permission decomposition may not be quote-aware, causing spurious prompts

Open 💬 1 comment Opened Jul 8, 2026 by fjrmur

\permissions.md\ documents that compound Bash commands are decomposed on \&&\, \||\, \;\, \|\, \|&\, \&\, and newlines, with each subcommand checked independently against allow/deny/ask rules. It's undocumented whether this decomposition respects quoting.

Example that still prompts for approval despite both \Bash(source:*)\ and \Bash(python3:*)\ being present in the allow list:

\\\
source venv/bin/activate 2>/dev/null; python3 -c "import ast; ast.parse(open('project.py').read())" && echo OK
\
\\

The \;\ inside the double-quoted Python argument may be getting treated as a shell-level separator, mis-splitting the command and preventing a clean match against the allow rules — even though each "real" subcommand (\source venv/bin/activate\, \python3 -c ...\, \echo OK\) is individually covered.

Could you confirm whether the decomposition is quote-aware, and if not, consider making it so (or documenting the limitation so users know to avoid embedding shell metacharacters inside quoted arguments when chaining commands)?

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗