Hook-creation flow can ship fragile bash-regex security restrictions without catching common bypasses

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)