clawband's own dry-run commands (clawband test) trigger the same ask/deny scanner they're used to safely probe

[jamessoubry]

Problem

Priority: reviews are actively being blocked by this — the Codex and Claude second-opinion review sessions (codex-clawband, claude-clawband-review) repeatedly need to construct adversarial test strings (dangerous git flag injections, heredoc-to-interpreter probes, etc.) to verify a rule correctly flags them. The documented, sanctioned way to do this is clawband test '<command>' ("Dry-run: print DENY/ASK/PASS without executing").

But invoking clawband test '<dangerous string>' still requires typing that dangerous string as a literal argument on the Bash command line. Claude Code's PreToolUse hook scans the outer Bash command text before clawband ever gets to run and recognize it's a no-op dry-run — so the tool's own safe introspection interface keeps triggering the exact ask/deny prompt it exists to test for, on the outer invocation, every single time.

Concrete evidence from ~/.clawband.log (2026-09-25/26, claude-clawband-review session testing PR #307's git-argument-injection fix): 6+ separate ASK hits in one session alone, each a different phrasing of the same underlying test (three distinct dangerous git flags, three different pipe-bypass variants) — none of them ever executed anything, all were clawband test/JSON-fixture-construction for verification. James has to manually approve every one, since:

• clawband skip enable is NOT project-scoped (single fixed path ~/.clawband/skip) — enabling it to unblock review testing would disable protection host-wide, including the live dev session writing real code. Not an acceptable trade.
• Per-pattern allowlisting is whack-a-mole — confirmed 6+ distinct patterns needed for one single bug's test coverage alone, and any new adversarial pattern class needs its own new allow-pattern.
• Instructing the review session (via prompt/nudge) to avoid inlining dangerous strings doesn't reliably work when the actual goal is specifically to feed those strings to clawband test for verification — there's no way to do that without the string appearing in the Bash command line.

Even filing this issue hit the same bug: describing the problem with a real example (rm -rf / as illustrative text) in the gh issue body got the outer gh issue create command itself blocked by clawband's deny-tier, on a completely different host session, confirming this is a general, structural problem with the scanner — not specific to the review sessions' workflow.

Proposed fix

Recognize invocations of clawband's own read-only introspection commands (clawband test '...', clawband log ..., clawband patterns, clawband stats) at the PreToolUse-Bash-hook level and treat the outer command as pass-tier unconditionally, regardless of what adversarial content appears inside the test argument — since by design, clawband test never executes the string it's given, only analyzes it and prints a decision.

Needs care on scoping: only the literal clawband test '<arg>'/clawband log/etc. invocation itself should be exempted, not anything downstream — e.g. a compound command that tacks a second, real executable statement onto a test call via ;/&& must still be caught by the existing compound-command-splitting logic, same as today. The exemption is for "this whole command is just a clawband test call," not "any command containing the string clawband test somewhere in it."

Priority

High — this is actively suppressing the value of the Codex/Claude second-opinion review pipeline. Reviews that find real bugs (e.g. PR #307's git pipe-bypass) still work, but every verification step generates manual-approval friction for James, and it doesn't scale as more rule classes get added.