Why Your AI Coding Agent Needs a Safety Guard: How Destructive Command Guard Prevents Catastrophic Mistakes — 3,200+ GitHub Stars

The Hidden Risk of AI Coding Agents

AI coding assistants have transformed how we build software. Claude Code, GitHub Copilot, Cursor, and similar tools can write, refactor, and debug code at superhuman speed. But there's a critical problem that most developers don't discover until it's too late: these agents occasionally execute catastrophic commands.

Picture this: You're working on a feature branch with hours of uncommitted changes. Your AI agent decides the cleanest way to resolve a merge conflict is to run git reset --hard HEAD~5. In milliseconds, your work is gone. Or maybe it runs rm -rf ./src thinking it's cleaning up temporary files. Or executes DROP TABLE users while helping you optimize a database query.

These aren't hypothetical scenarios. They're documented incidents that happen regularly across development teams using AI coding tools. The agents aren't malicious—they're just optimizing for the task at hand without understanding the irreversible consequences of certain commands.

Enter Destructive Command Guard (dcg)

Destructive Command Guard (dcg) is an open-source safety layer that sits between your AI coding agent and your terminal, intercepting dangerous commands before they can execute. Originally created by Jeffrey Emanuel as a Python script and later ported to Rust by Darin Gordon, dcg has grown into a comprehensive protection system with over 3,200 GitHub stars and is actively maintained by the developer community.

Unlike simple allowlists or manual approval workflows, dcg is:

• Zero-config out of the box — Blocks the most catastrophic git and filesystem commands immediately after installation
• Blazing fast — SIMD-accelerated filtering with sub-millisecond latency; you won't notice it's there
• Context-aware — Won't block grep "rm -rf" (searching for a string) but will block rm -rf / (actual deletion)
• Comprehensive — Scans heredocs, inline scripts, and complex command chains
• Extensible — 50+ modular security packs for databases, Kubernetes, Docker, cloud platforms, and more

How dcg Works Under the Hood

dcg operates as a hook that integrates with your AI coding agent's command execution pipeline. Here's the flow:

1. Interception: When your AI agent attempts to execute a command, dcg receives it first
2. Classification: The command is analyzed using SIMD-accelerated pattern matching and context detection
3. Decision: If the command matches a destructive pattern, dcg blocks it with a clear explanation
4. Feedback: The agent receives a structured denial message with safer alternatives
5. Logging: All blocked commands are logged for audit and debugging

Smart Context Detection

One of dcg's most powerful features is its ability to distinguish between data and execution. Consider these examples:

# This is SAFE (searching for a string in logs)
grep "rm -rf /" logs.txt

# This is BLOCKED (actually trying to delete everything)
rm -rf /

# This is SAFE (commenting about a dangerous command)
echo "Never run rm -rf / on your system"

# This is BLOCKED (executing the dangerous command)
bash -c "rm -rf /"

dcg uses advanced parsing to understand command context, including heredocs, inline Python/Node scripts, and complex shell chains. This means it catches creative ways agents might accidentally execute destructive code:

# Blocked: Python inline script trying to delete files
python -c "import os; os.remove('important_data.sql')"

# Blocked: Node.js script with destructive commands  
node -e "require('fs').unlinkSync('./config.json')"

# Blocked: Heredoc with dangerous commands
cat << 'EOF' | bash
git reset --hard HEAD~10
rm -rf ./node_modules
EOF

50+ Security Packs for Every Stack

dcg uses a modular "pack" system to organize protection by category. Out of the box, it enables the most critical packs:

• core.filesystem — Blocks rm -rf outside temp directories (always on, cannot be disabled)
• core.git — Blocks destructive git commands like reset --hard, clean -fd, and history-rewriting operations (always on)
• system.disk — Blocks mkfs, dd to devices, fdisk, and partition destruction

But the real power comes from enabling additional packs for your specific stack:

Database Protection

# ~/.config/dcg/config.toml
[packs]
enabled = [
    "database.postgresql",    # Blocks DROP DATABASE, TRUNCATE, dropdb
    "database.mysql",         # Blocks DROP DATABASE, mysqladmin drop
    "database.mongodb",       # Blocks dropDatabase, dropCollection
    "database.redis",         # Blocks FLUSHALL, FLUSHDB
    "database.sqlite",        # Blocks DROP TABLE, DELETE without WHERE
]

Cloud Infrastructure Protection

[packs]
enabled = [
    "cloud.aws",              # Blocks ec2 terminate-instances, s3 rb --force
    "cloud.gcp",              # Blocks gcloud compute instances delete
    "cloud.azure",            # Blocks az vm delete, az group delete
    "containers.docker",      # Blocks docker system prune, docker rm -f
    "containers.kubernetes",  # Blocks kubectl delete namespace, drain node
]

Storage and Backup Protection

[packs]
enabled = [
    "storage.s3",             # Blocks s3 rm --recursive, s3 sync --delete
    "storage.gcs",            # Blocks gsutil rm -r
    "remote.rsync",           # Blocks rsync --delete variants
]

Real-World Example: Saving a Production Database

Let's walk through a real scenario where dcg prevented a catastrophic mistake:

The Setup: A developer was using Claude Code to optimize a PostgreSQL query. The agent noticed that a table had millions of rows and suggested "cleaning it up" to improve performance.

The Dangerous Command:

-- Claude Code suggested this to "optimize the table"
TRUNCATE TABLE user_sessions;
VACUUM FULL user_sessions;

What Happened: With dcg enabled and the database.postgresql pack active, the command was intercepted:

════════════════════════════════════════════════════════════════
BLOCKED  dcg
────────────────────────────────────────────────────────────────
Reason:  TRUNCATE TABLE destroys all data without logging individual rows

Command: TRUNCATE TABLE user_sessions;

Pack:    database.postgresql
Rule:    truncate-table

Tip:     Consider using DELETE with a WHERE clause for selective removal,
         or archive data to a backup table first.
════════════════════════════════════════════════════════════════

The Outcome: The developer realized the agent was about to wipe the entire session table (which contained critical audit logs). Instead, they manually reviewed the query optimization and used DELETE FROM user_sessions WHERE created_at < '2024-01-01' to safely archive old sessions.

Without dcg, this would have been a production incident requiring database restoration from backups—potentially hours of downtime and data loss.

Installation and Configuration

Installing dcg takes less than a minute:

macOS / Linux

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh" | bash -s -- --easy-mode

Windows (PowerShell)

& ([scriptblock]::Create((irm "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.ps1"))) -EasyMode -Verify

The installer automatically detects your platform, downloads the correct binary, and configures hooks for all detected AI coding agents (Claude Code, Codex CLI, Gemini CLI, Copilot CLI, VS Code Copilot Chat, Cursor, Hermes Agent, and Grok).

Verification

After installation, verify dcg is working:

# Try a dangerous command
git reset --hard HEAD~5

# You should see a BLOCKED message from dcg

Escape Hatches: When You Really Need to Run a Blocked Command

Sometimes you do need to run a command that dcg blocks. dcg provides several escape hatches:

1. Environment Variable Bypass (Single Command)

DCG_BYPASS=1 git reset --hard HEAD~5

2. Allow-Once Code (From Block Message)

Every block message includes a short code. Copy it and run:

dcg allow-once abc123

3. Permanent Allowlist (For Recurring Commands)

dcg allowlist add core.git:reset-hard -r "Need to reset after bad commits"

4. Remove the Hook (Disable All Protection)

Edit your agent's configuration file (e.g., ~/.claude/settings.json) and remove or comment out the dcg hook entry.

Agent-Specific Trust Levels

dcg can apply different rules based on which AI agent is invoking it. This is useful if you trust certain agents more than others:

# Trust Claude Code more — wider allowlist, fewer packs
[agents.claude-code]
trust_level = "high"
additional_allowlist = ["npm run build", "cargo test"]
disabled_packs = ["kubernetes"]

# Restrict unknown agents — extra rules, no allowlist bypass
[agents.unknown]
trust_level = "low"
extra_packs = ["paranoid"]
disabled_allowlist = true

CI/CD Integration: Scan Mode

Beyond interactive development, dcg can be integrated into CI/CD pipelines to catch dangerous commands in code review:

# Scan a script for destructive commands
dcg scan ./deploy.sh

# Use as a pre-commit hook
dcg scan --pre-commit

This is especially valuable for teams where multiple developers (and their AI agents) contribute to shared scripts and automation.

Key Benefits

• Prevents catastrophic data loss — Blocks destructive git, filesystem, database, and cloud commands before they execute
• Zero-config protection — Works immediately after installation with sensible defaults
• Sub-millisecond latency — SIMD-accelerated filtering means no noticeable slowdown
• Context-aware — Distinguishes between searching for a string and executing a command
• Comprehensive coverage — Scans heredocs, inline scripts, and complex command chains
• 50+ security packs — Modular protection for databases, Kubernetes, Docker, AWS/GCP/Azure, Terraform, and more
• Multi-agent support — Works with Claude Code, Codex CLI, Gemini CLI, Copilot, VS Code Copilot Chat, Cursor, Hermes Agent, and Grok
• Escape hatches — Multiple ways to bypass protection when you genuinely need to run a blocked command
• CI/CD integration — Scan mode for catching dangerous commands in code review
• Open source — MIT licensed, actively maintained, and community-driven

Frequently Asked Questions

Q: Does dcg slow down my AI coding agent?

A: No. dcg is written in Rust and uses SIMD-accelerated pattern matching with lazy-compiled regex. Command classification typically completes in under 1 millisecond—you won't notice any performance impact.

Q: What if dcg blocks a command I actually need to run?

A: dcg provides multiple escape hatches: environment variable bypass (DCG_BYPASS=1), allow-once codes (from the block message), permanent allowlists, or removing the hook entirely. Most developers find that 95% of blocked commands are legitimately dangerous, and the remaining 5% can be safely allowlisted.

Q: Does dcg work with all AI coding agents?

A: dcg supports Claude Code, Codex CLI (0.125.0+), Gemini CLI, GitHub Copilot CLI, VS Code Copilot Chat, Cursor IDE, Hermes Agent, Grok (xAI), Antigravity CLI, OpenCode, Pi, and Aider (limited). The installer auto-detects and configures hooks for all detected agents.

Q: Can I use dcg in production CI/CD pipelines?

A: Yes. dcg includes a "scan mode" specifically designed for CI/CD integration. You can use it as a pre-commit hook, in pull request checks, or to scan deployment scripts for dangerous commands before they run in production.

Q: What's the difference between dcg and git hooks?

A: Git hooks (like pre-commit) only protect git operations and run after you've staged changes. dcg protects all commands (git, shell, database, cloud, etc.) and intercepts them before execution. They're complementary—use both for maximum protection.

Q: Is dcg open source? Can I contribute?

A: Yes, dcg is MIT licensed and hosted on GitHub. The project welcomes contributions, especially new security packs for specific tools and platforms. Check out the repository for contribution guidelines.

Q: How do I enable protection for specific databases or cloud platforms?

A: Edit ~/.config/dcg/config.toml and add the packs you need to the [packs] enabled list. For example: enabled = ["database.postgresql", "cloud.aws", "containers.docker"]. Run dcg packs --verbose to see all available packs.