`--permission-mode dontAsk`: `cp`/`mv` refuse any option token (including bare `--`) while the flagless form runs; `rm` is unaffected

Summary

Under --permission-mode dontAsk, with Bash allow rules for cp, mv, and
rm at the same breadth (e.g. Bash(cp:*), Bash(mv:*), Bash(rm:*)),
cp and mv are refused whenever the command carries any option token,
while their flagless (bare) forms run. rm is unaffected — rm -f and
rm -rf both run normally under the identical rule shape.

Repro table (measured on Claude Code 2.1.251, run E)

| command | result |
|---|---|
| cp -f | REFUSED |
| cp -v | REFUSED |
| cp -- | REFUSED |
| cp (bare) | RAN |
| mv -v | REFUSED |
| mv (bare) | RAN |
| rm -f | RAN |
| rm -rf | RAN |

Also confirmed:

• cp -f with relative paths — still REFUSED (not about absolute vs. relative paths)
• cp -f repeated as the last of several arms in the same session — still REFUSED (deterministic, not drift/a race)

Why this reads as a matcher artifact, not a safety policy

• cp -- is refused. -- is the POSIX end-of-options marker: it carries no

semantics a permission policy could plausibly want to withhold, yet it
trips the identical refusal as -f.

• rm -rf — by a wide margin the most destructive of the four commands —

runs unflagged under the identical Bash allow-rule shape. A rule
deliberately withholding force/destructive flags would refuse rm first,
not leave it alone while blocking an inert cp --.

Together these point at an implementation bug in how the dontAsk
permission matcher classifies cp/mv invocations carrying any token
after the command name, rather than a considered decision to gate those
two commands' options specifically.

Environment

• --permission-mode dontAsk
• Bash allow rules for cp, mv, rm at the same breadth
• Measured on Claude Code 2.1.251

Cost

Our own project guidance tells every agent to always pass a force flag on
cp/mv, specifically because those commands may be aliased to -i on a
developer's shell, which would otherwise hang a non-interactive session
forever waiting on a y/n prompt it cannot answer. Under dontAsk that
guidance is unfollowable for these two commands, and we had to write a
standing flagless-form exemption into our own docs to work around it.

Related

Searched before filing; no exact duplicate found. Related but distinct:
#16449 (quoted arguments starting with - misparsed), #30519 (permission
matching megathread). Neither covers this cp/mv-vs-rm asymmetry or the
option-token-vs-bare-form split.