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

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

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

Originally created by @rcdailey on GitHub (Jan 19, 2026).

Originally assigned to: @thdxr on GitHub.

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.

Originally created by @rcdailey on GitHub (Jan 19, 2026). Originally assigned to: @thdxr on GitHub. ### 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: ```json "bash": { "*": "allow", "gh api* -X DELETE*": "ask" } ``` This command bypasses the permission check entirely: ```bash 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: ```json "*gh api* -X DELETE*": "ask" ``` This matches the pattern anywhere in the command string, but it's non-obvious and easy to miss.
yindo commented 2026-02-16 18:05:28 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 19, 2026):

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

  • #8936: Bash: Default permission is "allow" - Related to permission system defaults
  • #8832: opencode not respecting permissions - Similar permission enforcement issue
  • #9511: [FEATURE]: Hierarchical rules triggered by file-related tool calls - Related to permission rule matching for files
  • #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.

@github-actions[bot] commented on GitHub (Jan 19, 2026): This issue might be a duplicate of existing issues. Please check: - #8936: Bash: Default permission is "allow" - Related to permission system defaults - #8832: opencode not respecting permissions - Similar permission enforcement issue - #9511: [FEATURE]: Hierarchical rules triggered by file-related tool calls - Related to permission rule matching for files - #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.
yindo commented 2026-02-16 18:05:29 -05:00
Author
Owner
Copy Link
Copy Source

@HeySora commented on GitHub (Feb 6, 2026):

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

@HeySora commented on GitHub (Feb 6, 2026): I will also add that `awk` can do system calls too, through something like `awk '{system("<command>")}'`
yindo commented 2026-02-16 18:05:29 -05:00
Author
Owner
Copy Link
Copy Source

@aspiers commented on GitHub (Feb 16, 2026):

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.

@aspiers commented on GitHub (Feb 16, 2026): 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.
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
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#6868
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?