You've given an AI coding agent access to your shell. It's smart, fast, and genuinely useful — until it isn't. One stray git reset --hard HEAD~5 or rm -rf ./src and three hours of uncommitted work are gone. The agent moves on. You don't.

This is the problem dcg (Destructive Command Guard) was built to solve.

What It Is

dcg is a hook written in Rust that sits between your AI coding agent and the terminal. When an agent tries to execute a command, dcg evaluates it first. If it matches a known destructive pattern — rm -rf, git reset --hard, DROP TABLE, kubectl delete namespace — it blocks the command, explains why, and suggests a safer alternative.

It supports Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, Cursor, Grok, and a handful of others. Install it once and every supported agent on the machine gets the guardrail automatically.

Why It's Worth Your Time

The obvious objection: "just review what the agent runs." That works until it doesn't. AI agents move fast. In a long session you'll start rubber-stamping commands — especially when everything has been fine for the past 30 minutes.

What makes dcg genuinely useful is that it's not a dumb blocklist. It's context-aware. Running grep "rm -rf" Makefile is data — it gets through. Running rm -rf /tmp/build during a cleanup step the agent invented on its own — that's where you want a second opinion.

It ships with 50+ modular security packs: PostgreSQL, MySQL, Docker, Kubernetes, AWS, GCP, Azure, Terraform, Vault, and more. Each pack is opt-in, so you enable only what's relevant to your stack. It also scans heredocs and inline scripts — catching something like python -c "import shutil; shutil.rmtree('./src')" before it executes.

Latency is sub-millisecond thanks to SIMD-accelerated filtering. You won't notice it.

Hands On

The install is a single curl command:

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" | bash -s -- --easy-mode

This auto-detects your platform, downloads the right binary, and configures hooks for whatever supported AI coding agents it finds on your system.

When an agent tries something dangerous, you see this instead of regret:

════════════════════════════════════════════════════════
BLOCKED  dcg
────────────────────────────────────────────────────────
Reason:  git reset --hard destroys uncommitted changes

Command: git reset --hard HEAD~5

Tip: Consider using 'git stash' first to save your changes.
════════════════════════════════════════════════════════

If you do need to run a blocked command, dcg allow-once <code> lets a single execution through without permanently weakening your protection. The code appears in the denial panel — no hunting through config files.

To enable additional protection for databases and containers, edit ~/.config/dcg/config.toml:

[packs]
enabled = [
    "database.postgresql",
    "kubernetes.kubectl",
    "containers.docker",
    "cloud.aws",
]

You can also tune trust per agent. If you want to give Claude Code a wider allowlist while locking down anything unknown:

[agents.claude-code]
trust_level = "high"
additional_allowlist = ["npm run build", "cargo test"]
disabled_packs = ["kubernetes"]

[agents.unknown]
trust_level = "low"
disabled_allowlist = true

And before you commit to a config change, you can test what would happen:

dcg explain "git reset --hard HEAD~5"

This shows exactly which rule would fire and why — useful when you're tuning the allowlist and want to verify your changes before they matter.

Honest Verdict

If you're using AI coding agents regularly — especially on projects with uncommitted changes or live infrastructure — dcg is worth five minutes of setup. It's not perfect. The fail-open design means parse errors and timeouts let commands through rather than blocking them, which is the right call for developer ergonomics but means this isn't a hard security boundary. It also carries a custom license rather than a standard OSI-approved one, worth checking before adoption in certain organizational contexts.

The core idea is exactly right. Context-aware filtering is what separates it from a glorified blocklist. It catches the catastrophic stuff — the commands where the window between "running" and "irreversible" is effectively zero.

I wouldn't call it a replacement for reviewing what your agent does. Think of it as a seatbelt. You still drive carefully. But you wear it anyway.

Go Try It

→ github.com/Dicklesworthstone/destructive_command_guard

Start with --easy-mode. Then run dcg explain on a few commands from your typical workflow to understand exactly what's being watched.