Description
When asked to create a Bash PreToolUse/PermissionRequest hook restricting rm -r/rm -rf to specific paths, Claude implemented it as a grep -qE '^rm -r...' bash one-liner and declared it tested/working after checking only the happy-path case (rm -rf /allowed/path/...).
Only after the user explicitly asked "what about rm -rf?" as a follow-up did Claude actually stress-test the hook — at which point it turned out the regex silently failed to catch:
rm -Rf, rm -fr, rm --recursive --force (flag order/case/long-form variants — the regex only matched a literal -r immediately after rm )sudo rm -rf ... and any leading wrapper (env X=Y rm -rf, cd /x && rm -rf, etc.) — the regex only matched when the command started with rm -r- Path traversal (
rm -rf /tmp/../etc/foo) — string-prefix matching, no real path resolution
- Compound commands (
rm -rf /etc && echo done) — only the first token sequence was ever considered
None of these were caught proactively by Claude — the fix only happened because the user pushed back with a follow-up question. The safety guarantee of the hook was materially weaker than what was presented as "verified."
Ask
When a user requests a hook whose purpose is a security/safety restriction on a destructive command (rm -rf, git reset --hard, docker rm, etc.), Claude should default to a real command parser (e.g. a shlex-based script that resolves actual paths) rather than a bash regex, and should proactively test adversarial bypass patterns (flag reordering, sudo/wrapper prefixes, path traversal, compound commands) before declaring the hook verified — rather than waiting for the user to catch the gap.
Environment
- Claude Code CLI 2.1.207 (native install, darwin-arm64)
- Backend: AWS Bedrock (
CLAUDE_CODE_USE_BEDROCK=1)
Description
When asked to create a Bash
PreToolUse/PermissionRequesthook restrictingrm -r/rm -rfto specific paths, Claude implemented it as agrep -qE '^rm -r...'bash one-liner and declared it tested/working after checking only the happy-path case (rm -rf /allowed/path/...).Only after the user explicitly asked "what about rm -rf?" as a follow-up did Claude actually stress-test the hook — at which point it turned out the regex silently failed to catch:
rm -Rf,rm -fr,rm --recursive --force(flag order/case/long-form variants — the regex only matched a literal-rimmediately afterrm)sudo rm -rf ...and any leading wrapper (env X=Y rm -rf,cd /x && rm -rf, etc.) — the regex only matched when the command started withrm -rrm -rf /tmp/../etc/foo) — string-prefix matching, no real path resolutionrm -rf /etc && echo done) — only the first token sequence was ever consideredNone of these were caught proactively by Claude — the fix only happened because the user pushed back with a follow-up question. The safety guarantee of the hook was materially weaker than what was presented as "verified."
Ask
When a user requests a hook whose purpose is a security/safety restriction on a destructive command (
rm -rf,git reset --hard,docker rm, etc.), Claude should default to a real command parser (e.g. ashlex-based script that resolves actual paths) rather than a bash regex, and should proactively test adversarial bypass patterns (flag reordering, sudo/wrapper prefixes, path traversal, compound commands) before declaring the hook verified — rather than waiting for the user to catch the gap.Environment
CLAUDE_CODE_USE_BEDROCK=1)