- add handlers/xargs.ts mirroring env: claim xargs-leading commands and defer - register xargsHandler so leading-xargs commands log and defer instead of falling through silently - add CONTEXT.md xargs example and ADR 0003 (xargs args come from stdin, so even the AI judge cannot know them)
1.8 KiB
status
| status |
|---|
| accepted |
Defer xargs; it is non-transparent even to the AI judge
xargs is a third command type considered for pi-permission-inner-cmd. Like
env (ADR 0002), inner-cmd always defers it and never unwraps. Unlike env,
the non-transparency is in the inner command's arguments, not its environment.
Why
xargs [options] [command [initial-args]] reads tokens from stdin (or -a FILE) and appends them as arguments to command. The command string therefore
holds only the command name (plus any initial args); the bulk of what the
command actually does — its runtime arguments — comes from a separate channel
that is absent from the string entirely. Re-evaluating the inner command is
unsound: the verdict would apply to arguments that are not even knowable from the
input (xargs rm can become rm over any list of files). -I / -i, -a,
-P, -o further alter behavior.
There is no sound unwrap subset (unlike env's rare bare form): xargs always
draws its arguments from an external source, so the inner command is never fully
determined by the string.
Consequences
- inner-cmd registers an
xargshandler that claimsxargs-leading commands and defers them (mirroringenv), for observability. Note thatxargsusually appears mid-pipeline (find … | xargs rm), where inner-cmd's leading-program check never reaches it and it defers by default regardless. - The deferred command reaches the AI judge — but the AI judge also cannot see
stdin, so it cannot know the actual arguments either.
xargscommands therefore typically warrant a human ask rather than an auto-allow, even with AI judgement; the sound outcome is human confirmation.
See ADR 0002 for the sibling env decision and CONTEXT.md for the
non-transparent wrapper distinction.