Repo of the day: Destructive Command Guard, the emergency brake for AI agents

🛡️ What dcg is: a pre-execution guardrail, not a sandbox

Destructive Command Guard is a Rust binary that plugs into the hook mechanism of coding agents: when the agent is about to run a shell command, dcg receives it before execution, analyzes it and decides — allow silently, or block with a message explaining why and suggesting the safe path. The problem it solves is concrete: models occasionally run catastrophic commands like `git reset --hard`, `rm -rf ./src` or `DROP TABLE users`, destroying hours of uncommitted work in seconds.

The project started in January 2026 as the author's Python script, was then rewritten in Rust with Darin Gordon and has grown to the current v0.6.8: over 1,700 commits, signed binaries (mandatory SHA256, minisign, Sigstore) and a declared philosophy — it's a guardrail, not a complete security boundary. That distinction matters and I come back to it below: a hook filters intent, a sandbox limits the blast radius.

repo       Dicklesworthstone/destructive_command_guard
stars      ~4,500 · forks 169 · language Rust · custom license
authors    Jeffrey Emanuel (concept + pack system) · Darin Gordon (Rust port)
what       pre-execution hook: blocks agents' destructive commands
harness    Claude Code · Codex CLI · Gemini CLI · Copilot CLI · Cursor · more
extra      50+ optional security packs · sub-millisecond latency

⚙️ How it works: three tiers and a 200-millisecond budget

The part that convinced me to feature it is the latency engineering. A guard that slows down every command would get uninstalled in an afternoon, so dcg uses a three-tier pipeline: a first screening with compiled regular expressions rejects, in under 100 microseconds, everything that contains no suspicious triggers — the vast majority of commands. Only what remains moves on to content extraction (heredocs, inline scripts, `-c` arguments) and finally to structural AST matching via tree-sitter, which understands the difference between an `rm -rf` quoted inside a `grep` and one that will actually be executed.

On top of everything sits a common-sense rule: an absolute cap of 200 milliseconds. If analysis exceeds the budget, the command goes through anyway and a warning is logged. It's the project's declared fail-open choice: a blocked legitimate command is more disruptive than a missed dangerous one — anyone who prefers the opposite can enable fail-closed with one line of configuration.

🚀 Installation: one command, hooks configured for every agent

The "easy mode" install does everything on its own: it detects the platform, downloads the right binary, verifies SHA256 checksums and signatures, configures hooks for every supported agent it finds on the machine and updates the PATH. On Claude Code it registers a `PreToolUse` hook with a `Bash` matcher in `settings.json` — the same mechanism I use for end-of-session quality gates, here applied upstream of every command. On Codex CLI (0.125.0+) the hook lands in `hooks.json`, on Gemini CLI it becomes a `BeforeTool` on `run_shell_command`, and Cursor, Copilot CLI and Grok have their own documented paths.

After installing, it's worth running `dcg setup`, which adds a shell-startup check: if the hook ever gets removed from `settings.json` — by an update, or by an overly enterprising agent — you find out immediately instead of discovering it at the next disaster.

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

# verify: this gets blocked...
dcg test "git reset --hard"

# ...this doesn't (it's data, not execution)
dcg test "grep 'rm -rf' README.md"

# understand a decision, with per-stage timings
dcg explain --verbose "rm -rf /tmp/build"

🧰 Security packs: from git to Stripe, active only where needed

By default dcg protects the essentials: `core.git` and `core.filesystem` (always on, cannot be disabled) plus `system.disk` against disk- and partition-level disasters. Everything else is opt-in through more than 50 themed packs: databases (PostgreSQL, MySQL, MongoDB, Redis), Kubernetes, Docker, cloud (AWS, Azure, GCP), Terraform, and even packs for services like Stripe, Cloudflare or SendGrid. The logic feels right to me: you only enable the guardrails for the infrastructure your agents actually touch, without paying false positives on everything else.

Configuration is a layered TOML — system, user, project (`.dcg.toml` in the repo root) — with per-project overrides and even per-agent profiles. And when a block is legitimate there are escape valves: `dcg allow-once` with a six-digit code for one-off exceptions, permanent allowlists with a mandatory reason, and `DCG_BYPASS=1` to disable everything for a single invocation.

# ~/.config/dcg/config.toml
[packs]
enabled = [
    "database.postgresql",    # blocks DROP TABLE, TRUNCATE
    "kubernetes.kubectl",     # blocks kubectl delete namespace
    "containers.docker",      # blocks docker system prune
]

# per-project exceptions, with a reason
# dcg allowlist add core.git:reset-hard --reason "CI cleanup" --project

🏢 Why it's interesting, for developers and SMBs

For those developing with agents, dcg takes the worst error category off the table: the irreversible one. Vibe coding works precisely because you grant the agent a lot of autonomy, and more autonomy means more commands executed without human review; a deterministic, fast, transparent filter on that surface is a tiny investment — one install command — against a risk anyone who has lost a stash or a branch knows well. And the fact that the block comes with an explanation also helps the agent itself, which usually falls back on the suggested safe alternative on its own.

For an SMB adopting AI agents in its development processes, dcg is a concrete governance building block: an executable security policy, versionable in the repo (`.dcg.toml`) and identical for everyone — developers and agents alike. It's the same logic I wrote about when covering shadow AI and agent governance: rules are worth little if they live in a document; here they become an active technical control on every workstation, with decision logs and motivated exceptions. It doesn't replace backups, permissions and review — it completes them at the exact point where agents actually operate.

⚠️ The limits to know before trusting it

The README is honest about its boundaries, and I report them because that's where a serious adoption is decided. First: a hook is not a sandbox — an agent can write a script to disk and execute it through a path the hook doesn't intercept; the project itself asks you to treat it as a guardrail, paired with restricted credentials, backups and branch protection. Second: the fail-open default means timeouts and parse errors let the command through — a sensible ergonomics choice, but one you need to know (and can invert). Third: coverage varies per harness — on Aider it's limited to git hooks, on Continue there's no interception.

One last note: the license is custom, not a standard MIT or Apache. For personal use nothing changes in practice, but a company planning a structured adoption should read it first — the principle I apply to every repo of the day holds: trending is a discovery signal, not a completed due diligence.

• Not a sandbox: it filters commands in transit, it doesn't limit what an already-running process can do.
• Fail-open by default: past 200ms or on an analysis error the command passes; `DCG_FAIL_CLOSED=1` inverts the behavior.
• Uneven coverage: full on Claude Code, Codex, Gemini and Cursor; partial on Aider, absent on Continue.
• Custom license: read it before a structured company adoption.

✅ Where to start

The path I suggest: install in easy mode on a development machine, check with `dcg test` that the fundamental patterns get blocked, and work for a week with just the default packs — in my experience false positives on the daily flow are rare, and when they happen `dcg explain` tells you exactly which rule fired and why. Then enable the packs for your real infrastructure, one at a time, and commit the project's `.dcg.toml` so the protection travels with the repo.

In the bigger picture, dcg completes the triad I've been writing about for weeks: method (Superpowers and structured workflows) reduces design mistakes, quality gates via hooks check the result at the end of the session, and dcg guards the only point where a mistake can't be recovered: the destructive command that gets executed. Three different layers, same idea: give agents autonomy without handing them the keys to everything.

More articles from the blog