[FEATURE]: Extract inner commands from xargs/parallel/find -exec for permission matching

[rcdailey]

Problem

When a command is wrapped in xargs, find -exec, parallel, watch, or similar command wrappers, the permission system only sees the wrapper command, not the inner command being executed.

For example, with this permission config:

"bash": {
  "*": "allow",
  "gh api* -X DELETE*": "ask"
}

This command bypasses the permission check entirely:

gh api repos/owner/repo/code-scanning/analyses --paginate -q '.[] | .id' | xargs -I{} gh api -X DELETE repos/owner/repo/code-scanning/analyses/{}

The bash tool parses this as two commands via tree-sitter:

1. gh api repos/... --paginate -q '...' - matches *: allow
2. xargs -I{} gh api -X DELETE ... - starts with xargs, not gh api, so matches *: allow

The dangerous gh api -X DELETE is never checked because it appears as arguments to xargs, not as a standalone command.

Proposed Solution

The bash tool could recognize common command wrappers and extract their inner commands for permission checking:

• xargs [-I...] <command> - extract command after flags
• find ... -exec <command> \; or -exec <command> + - extract command between -exec and terminator
• parallel <command> - extract command
• watch [-n...] <command> - extract command after flags
• env [VAR=val...] <command> - extract command after env vars

When a wrapper is detected, both the wrapper invocation AND the inner command should be checked against permission rules.

Workaround

Users can currently work around this by adding a leading * to patterns:

"*gh api* -X DELETE*": "ask"

This matches the pattern anywhere in the command string, but it's non-obvious and easy to miss.

[github-actions]

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

• Bash: Default permission is "allow" #8936: Bash: Default permission is "allow" - Related to permission system defaults
• opencode not respecting permissions #8832: opencode not respecting permissions - Similar permission enforcement issue
• [FEATURE]: Hierarchical rules triggered by file-related tool calls for progressive disclosure #9511: [FEATURE]: Hierarchical rules triggered by file-related tool calls - Related to permission rule matching for files
• [BUG] a is not accepted as always accept permission #9390: [BUG] a is not accepted as always accept permission - Related to permission system bugs

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

[HeySora]

I will also add that awk can do system calls too, through something like awk '{system("<command>")}'

[aspiers]

And perl / python / ruby / node ... in fact pretty much any language interpreter will allow that! If your default policy is allow then all bets are off and you will need some other form of protection e.g. kernel-level sandboxing.

[Chetic]

This also affects simple execution wrappers like timeout, time, nice, nohup, ionice, and stdbuf. These don't change what runs, only how — but the permission system treats them as the command:

# "git log*": "allow" configured, but this still prompts:
timeout 5 git log --oneline

# Same for:
nice -n 10 grep -r "TODO" src/
time git status

These wrappers have simpler argument patterns than xargs/find -exec, so they'd be a good starting point for implementation.

[Chetic]

I've opened a PR implementing this: #16724

It adds a BashWrapper module that extracts inner commands from wrapper commands (timeout, sudo, xargs, nohup, nice, env, find -exec, etc.) so both the wrapper and inner command get checked against permission rules. This prevents bypasses like sudo rm -rf / evading "rm *": "deny".

[github-actions]

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