sensitive-file-guard blocks Bash execution (not just edits) of protected helper scripts, breaking /cprune and /cauto ABS-030

[joshft]

Summary

hooks/sensitive-file-guard.sh blocks Bash commands that execute or source a protected helper script, not just commands that edit it. Because the guard's protected-pattern set hardcodes bare helper-script filenames, any bash <script> / source <lib> whose argument matches is rejected with BLOCKED [sensitive-file]: <target> matches protected pattern '<name>' — even for read-only execution. Worse, the matcher is a substring match over the whole command string, so even referencing a protected filename inside an unrelated command (e.g. a log line or an issue body) trips it. This makes several skill-prescribed invocations unusable.

Affected (hardcoded in the guard's protected list)

The guard hardcodes bare-filename + path variants for, at least: the shared lib script, the autonomous-decision writer, the prune scanner, the audit-record writer, and the harness-fingerprint script. Each is matched as a Bash target, so executing/sourcing it is blocked.

Root cause

_extract_bash_targets pulls the script path out of the Bash command and matches it against the protected-pattern list. The intent is to prevent the agent from editing these sensitive scripts, but the matcher cannot distinguish bash <script> / source <lib> (execute/read) from a write, and it substring-matches the entire command rather than parsing redirect targets. The fast-path that skips non-write Bash commands does not exempt these — a read-only invocation that names a protected filename is still blocked.

This directly contradicts a design assumption in the /cauto SKILL.md (the ABS-030 sole-writer section), which states the writer script may be invoked via Bash because "the SFG permits this because the Bash command contains no direct redirect to the protected path." In practice the guard matches the path itself, not just redirects, so invoking the writer script is blocked — the skill's stated contract with the guard is false.

Reproduction

In a project with the guard installed, run any of these read-only commands (paths abbreviated):

• bash <correctless>/scripts/<prune-scanner>.sh --category counts --base .
• bash <correctless>/scripts/<autonomous-decision-writer>.sh append <skill> '<json>'
• source <correctless>/scripts/<lib>.sh (e.g. to call the branch-slug helper)

Each is rejected: BLOCKED [sensitive-file]: ...<scanner>.sh matches protected pattern '<scanner>.sh'.

Impact

• /cprune (autonomous, in the /cauto pipeline): its sole detection mechanism is the prune scanner. With execution blocked, the scanner cannot run and the whole skill is unusable (must be skipped).
• /cauto ABS-030: the sole-writer flow for the per-branch autonomous-decisions JSONL routes through the writer script. Blocked → the orchestrator cannot record autonomous decisions via the prescribed path (must append to the JSONL directly, bypassing the script's branch-slug/dir-creation logic).
• Any skill/step that sources the shared lib via Bash to get the branch-slug helper (and similar) fails; callers must hand-reimplement the slug.

Suggested fix

Distinguish write/edit targets from execute/source targets in the guard. Options:

1. For Bash, only treat a protected path as a violation when it is the target of a write redirect (>, >>, tee, a cp/mv/rm destination, or an Edit/Write tool) — not when it is the program being executed (bash X, sh X, source X, . X, or ./X), and parse redirect targets rather than substring-matching the whole command.
2. Maintain a separate allowlist of "protected-but-executable" helper scripts that may be invoked but not edited.

Either way, the skills that depend on invoking these helpers (/cprune, /cauto ABS-030, anything sourcing the shared lib) should round-trip cleanly.

Environment

Found during an autonomous /cauto run (high intensity). Guard hook + the cprune/cauto skills are the installed plugin versions.

[joshft]

Another concrete instance of this (filed separately as #203, which I'm closing as a duplicate of this broader report): the /cauto ABS-030 sole-writer contract prescribes invoking the autonomous-decision-writer helper via bash <dir>/scripts/<writer>.sh append …, but the SFG over-extracts the script path as a non-flag command token and matches it against the protected-files list → BLOCKED on invocation. The /cauto SKILL.md even asserts the invocation is permitted ("no direct redirect to the protected path") — but the guard matches the path as a plain argument, not only as a redirect target. Same root cause and same suggested fix as this issue: treat a protected script appearing as the interpreter target of bash/sh <script> as an allowed invocation, distinct from an edit or redirect target.

(Meta: filing this very cross-reference tripped the bug — the guard blocked the gh command because the comment text contained the helper script's filename as a bare token, so the path had to be elided to post it.)