bash permission rules non-deterministic for rm *, mv *, cp * patterns #39001

Activity

1. github-actions commented on Jul 26, 2026

   

   github-actionsBot

   on Jul 26, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • permission.bash pattern maps: "*": "deny" fallback removes the bash tool from all agents; deny patterns under an allow fallback are ignored #36765: permission.bash deny patterns under an allow fallback are silently ignored — overlapping root cause (bash permission rules not reliably enforced)
   • [FEATURE]: fix recurring bash permission bypasses with a structural parser #31485: Feature request for a structural parser to fix recurring bash permission bypasses — same underlying class of issue
   • Permission rules match rewritten shell commands after tool.execute.before hooks #35882: Permission rules matching rewritten shell commands — related bash permission bypass

   If your issue is distinct from all of the above, please add a comment clarifying the difference.
2. github-actions

   assigned

   kitlangton

   on Jul 26, 2026
3. aanbrn commented on Sep 17, 2026

   

   aanbrn

   on Sep 17, 2026

   More actions

   Adding a reproducible input for this class, from a push that was silently allowed, plus an observation that the
   reduction is not stable across identical shapes — which may be the same thing you measured.

   The input (in a scratch clone, since the second line really pushes):

   git switch -c probe-nginx-121-on-x86 --no-track origin/main 2>&1 | tail -1 | sed 's/^/  /'
   git push -u origin probe-nginx-121-on-x86 2>&1 | tail -2 | sed 's/^/  /'

   with "permission": {"bash": {"*": "allow", "git push*": "ask"}} on 1.18.31 (macOS). In the log, the push
   line's head was committed to the previous line's sed, and the line's own tail split into further units, so
   the string the permission check received begins with sed:

   permission=bash pattern="sed 's/^/  /'\ngit push -u origin probe-nginx-121-on-x86"  -> action.pattern=* action=allow
   permission=bash pattern="tail -2"                                                    -> action.pattern=* action=allow
   

   (condensed from ~/.local/share/opencode/log/opencode.log; the evaluated payloads are exact.) The anchored git push* cannot match a string starting with sed, so the catch-all decides, and no prompt appears. A push of the
   same shape, reduced with git push … 2>&1 as its own unit, does match:

   permission=bash pattern="git push -u origin capture-cnb-fixed-timestamp 2>&1"        -> action.pattern="git push*" action=ask
   

   The same shape is not always split the same way. For the same predecessor shape — a git commit … && echo …
   line
   followed by a push with the same 2>&1 | tail -2 | sed … tail — two invocations reduced it differently: once
   the echo and the push were separate units and the push matched git push* and prompted, and once the two were
   merged into one unit and the push was silently allowed:

   permission=bash pattern="echo \"  committed\""          -> action.pattern=*            action=allow
   permission=bash pattern="git push -u origin fix-per-service-compose-tasks 2>&1" -> action.pattern="git push*" action=ask
   permission=bash pattern="echo \"  committed\"\ngit push" -> action.pattern=*            action=allow
   

   So the split depends on more than the visible shape of the call, which is consistent with the 50–90 % bypass
   rates you measured and with the matcher being correct — the input to it is what varies.

   How this relates to the linked issues: #36765 and #31485 were closed, so the useful thing I can add is a
   concrete input plus the observation that the anchored rule does fire when the reduction is clean. No
   command-rewriting plugins are involved here, so #35882 is a different path.

   Workaround we adopted: anchor on both sides — *git push* instead of git push* — since the rule no longer
   requires the string to begin with the command. The expected cost is over-asking on commands that merely mention
   it (a grep, a commit message), because that is how substring matching behaves.
4. JasperTeng commented on Sep 30, 2026

   

   JasperTeng

   on Sep 30, 2026

   More actions

   I just tested OpenCode 1.18.33.
   "git push*": "deny" does not block ... && git push ...
"*git push*": "deny" does not block git push ...
5. mahirhir commented on Oct 6, 2026

   

   mahirhir

   on Oct 6, 2026

   More actions

   I traced this on dev (f03046d) with the real ShellTool: a bun test that captures the bash permission request and runs each pattern through Permission.evaluate with {"*": "allow", "rm *": "ask", "git push*": "ask"}. There are two causes. Both are deterministic, and neither is a race.

   1. The 50% in the report comes from the model, not the matcher. The prompt asks for bash -c 'rm /tmp/test_$i.txt'. The pattern that gets checked is the source text of each tree-sitter command node (source() / collect() in src/tool/shell.ts). When the model passes the command through verbatim, the pattern is bash -c 'rm ...', which rm * can't match, so *: allow wins. When the model unwraps it, the pattern is rm /tmp/test.txt and the rule fires. That's the prompt shown in the report (permission requested: bash (rm /tmp/test.txt)). Wildcard.allStructured isn't on this path; the only place it's referenced is test/util/wildcard.test.ts.

   It's the same root cause for these other spellings, which also run rm and evaluate to allow. Only the control also raises external_directory for /tmp; none of the other rows do, because tokens[0] isn't rm:

   command	pattern(s) evaluated	verdict
   rm /tmp/x (control)	rm /tmp/x	ask
   bash -c 'rm /tmp/x'	bash -c 'rm /tmp/x'	allow
   sudo rm /tmp/x	sudo rm /tmp/x	allow
   \rm /tmp/x	\rm /tmp/x	allow
   /bin/rm /tmp/x	/bin/rm /tmp/x	allow
   echo /tmp/x | xargs rm	echo /tmp/x, xargs rm	allow
   git push origin main	git push origin main	allow (raw text is matched, not tokens)

   2. @aanbrn's sed ... + newline + git push case is a tree-sitter-bash grammar bug. It shows up in the pinned 0.25.0 and in 0.25.1. It happens when line N ends in a pipeline of 3+ commands and line N+1's first command is followed by a redirection (2>&1, > f) or by &&/||. The grammar then folds that command into the arguments of the last command on line N, and hasError stays false. Minimal case: a | b | c + newline + rm -rf /tmp/x 2>&1 gives the patterns a, b, c\nrm -rf /tmp/x, which evaluates to allow. The && form is already reported upstream as tree-sitter/tree-sitter-bash#347. The redirection form is the one agent commands hit, because most of them end in 2>&1. In that case tokens[0] is c, so the external_directory check in collect() is skipped for that rm as well.

   Patch sketch. I tested this on a copy of collect() running against the real grammar. Dangerous forms allowed went from 15/17 to 0/17, and the verdicts for 9 benign controls didn't change. The idea is to keep source(node) as it is and add normalized patterns. Permission.ask asks if any pattern asks, so adding patterns can only make a rule stricter. The added patterns:

   • the tokens joined by single spaces;
   • the head with a leading \ or a path prefix stripped;
   • the argv left after stripping wrappers (sudo, doas, command, builtin, exec, env, nice, nohup, time, timeout, xargs, stdbuf) and their options and VAR=x prefixes;
   • the result of re-parsing the string argument of sh/bash/zsh -c and eval, and the argv after find -exec/-execdir/-ok;
   • for the grammar bug: when a token in a command node starts on a later row than the previous token ended, with no \ continuation, split the node there and re-parse the rest.

   I can turn this into a PR with these cases in test/tool/shell.test.ts if @kitlangton wants it. Otherwise, feel free to use the table.
6. samvallad33 commented on Oct 8, 2026

   

   samvallad33

   on Oct 8, 2026

   Last edited by samvallad33

   More actions

   a rule that fires half the time on rm and one time in ten on mv is worse than no rule, because you can't trust the passes either.

   pattern rules fight the shell itself. by the time a string runs it has been quoted and globbed and expanded, so the pattern is guessing at the result.

   I built a small gate that goes the other way. it resolves the command first and then decides from what it would touch, so the same command gets the same answer every run. it does not ask on every rm or mv. it stops the destructive ones it knows, like a recursive delete outside the project, and lets the rest through.

   it is free and part of vestige.

   npx operator-lite

   on mac and linux it installs for opencode. it starts in shadow, records everything and blocks nothing.

   npx operator-lite mode enforce

   that turns blocking on, from your own terminal.
7. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
8. thdxr

   closed this as not plannedon Oct 11, 2026