Observation
While the clean skill is active, its frontmatter PreToolUse belt denies every Bash command except the engine's own literal invocations. That is the documented deny-by-default posture and it does what it says.
The cost showed up in a real session: ls -d <path> — a read-only existence test — was rejected with the full deletion-guard denial message. The skill's documentation anticipates this ("Supporting research uses non-Bash read-only tools"), so the behavior is intended.
Why it is still worth reconsidering
In the same session the PowerShell lane was simultaneously constrained by a separate defect (guardrails' block-dangerous-git.sh rejecting any script that merely mentions .git — filed separately). The combination left no straightforward lane for ordinary read-only inspection during a cleanup run: Bash denied everything, PowerShell rejected the idiomatic ForEach-Object { } form.
Cleanup work is inspection-heavy by nature. The deletion authority is the engine's own containment, identity, and handle checks — not the belt — so a deny-all Bash lane buys less than it costs here.
Question for maintainers
Should the belt carry a small, explicitly read-only allowlist (ls, test, stat, file) rather than deny-all?
Arguments against are real and should be weighed: an allowlist is a parsing surface, and the belt's current strength is that it does not try to parse anything. A narrow literal-form allowlist with no shell metacharacters, no operators, and no redirections may thread that needle — or may not be worth the complexity, in which case closing this as working-as-intended is a fine outcome.
Observation
While the
cleanskill is active, its frontmatter PreToolUse belt denies every Bash command except the engine's own literal invocations. That is the documented deny-by-default posture and it does what it says.The cost showed up in a real session:
ls -d <path>— a read-only existence test — was rejected with the full deletion-guard denial message. The skill's documentation anticipates this ("Supporting research uses non-Bash read-only tools"), so the behavior is intended.Why it is still worth reconsidering
In the same session the PowerShell lane was simultaneously constrained by a separate defect (guardrails'
block-dangerous-git.shrejecting any script that merely mentions.git— filed separately). The combination left no straightforward lane for ordinary read-only inspection during a cleanup run: Bash denied everything, PowerShell rejected the idiomaticForEach-Object { }form.Cleanup work is inspection-heavy by nature. The deletion authority is the engine's own containment, identity, and handle checks — not the belt — so a deny-all Bash lane buys less than it costs here.
Question for maintainers
Should the belt carry a small, explicitly read-only allowlist (
ls,test,stat,file) rather than deny-all?Arguments against are real and should be weighed: an allowlist is a parsing surface, and the belt's current strength is that it does not try to parse anything. A narrow literal-form allowlist with no shell metacharacters, no operators, and no redirections may thread that needle — or may not be worth the complexity, in which case closing this as working-as-intended is a fine outcome.