Auto Dangerous Command Blocker

Provides multi-level protection against destructive shell commands by blocking catastrophic operations, protecting critical paths, and warning about suspicious patterns.

When to Use This Hook

Attach this hook when you need to:

• Prevent accidental execution of destructive commands like rm -rf /, dd, or mkfs
• Protect critical directories (.git, .claude, node_modules) from deletion or modification
• Add a safety layer for junior developers or automated scripts running shell commands

Consider alternatives when:

• Your environment already has OS-level protections (e.g., immutable infrastructure, read-only mounts)
• You need to run destructive commands intentionally and the blocker creates friction

Quick Start

Configuration

Copy
name: auto-dangerous-command-blocker
type: hook
trigger: PreToolUse
category: security

Example Trigger

Copy
# Hook triggers before any Bash command execution
claude> rm -rf node_modules/.cache
# Blocker analyzes the command for dangerous patterns

Example Output

Dangerous Command Blocker: Analyzing command...
  Command: rm -rf node_modules/.cache
  Level 1 (Catastrophic): PASS
  Level 2 (Critical Path): WARNING - node_modules path detected
  Level 3 (Suspicious Pattern): PASS
  Decision: ALLOWED with warning
  Note: node_modules/.cache is a safe target for cleanup

Core Concepts

Protection Levels Overview

Aspect	Details
Level 1: Catastrophic	Blocks rm -rf /, dd if=/dev/zero, mkfs, :(){ :|:& };:
Level 2: Critical Paths	Warns on operations touching .git/, .claude/, /etc/
Level 3: Suspicious	Flags chmod 777, curl | sh, recursive deletes on home dir
Implementation	Python script reading command from stdin JSON
Exit Behavior	Exit 2 to block, exit 0 to allow, warnings to stderr

Command Analysis Workflow

Bash Command Intercepted
         |
   Parse Command String
         |
   Level 1: Catastrophic?
    /            \
  Yes             No
   |               |
  BLOCK       Level 2: Critical Path?
  (exit 2)     /            \
             Yes             No
              |               |
            WARN        Level 3: Suspicious?
            + Allow      /            \
                       Yes             No
                        |               |
                      WARN           ALLOW
                      + Allow       (clean)

Configuration

Parameter	Type	Default	Description
catastrophic_patterns	string[]	["rm -rf /","dd if=","mkfs","fork bomb"]	Commands that are always blocked
critical_paths	string[]	[".git/",".claude/","node_modules/","/etc/"]	Paths that trigger warnings on modification
suspicious_patterns	string[]	`["chmod 777","curl	sh","wget
block_level	string	"catastrophic"	Which level triggers blocking vs warning
whitelist	string[]	[]	Command patterns that bypass all checks

Best Practices

1. Never Whitelist Destructive Patterns - Whitelisting rm -rf for convenience defeats the purpose. Instead, be more specific in your commands and let the blocker verify each one.

2. Log All Blocked Commands - When a command is blocked, log it with timestamp and context. This creates an audit trail and helps identify patterns where Claude is attempting inappropriate commands.

3. Customize Critical Paths per Project - Add project-specific critical paths (e.g., migrations/, secrets/, certs/) to the protection list. The defaults cover common paths, but every project has unique critical directories.

4. Review Warning-Level Events - Warnings are not blocks, so they do not prevent execution. Periodically review warnings to decide whether any should be elevated to blocking rules.

5. Combine with File Protection - The command blocker catches shell commands, but direct file edits bypass it. Pair it with the file protection verifier to cover both attack vectors.

Common Issues

1. False Positives on Safe Commands - rm -rf node_modules is generally safe but matches the rm -rf pattern. The blocker should analyze the full path, not just the command prefix.

2. Bypassing via Command Chaining - Commands like echo "test" && rm -rf / can hide dangerous operations. The blocker must parse the full command chain, not just the first segment.

3. Different Shell Syntax - Users may use \rm, command rm, or shell aliases to bypass pattern matching. The blocker should normalize commands before pattern matching.