Destructive Command Guard (dcg) is an open-source hook that stops AI coding agents from running destructive git and shell commands before they execute. For teams that already let Claude Code, Codex CLI, or similar agents run shell commands, it is worth evaluating now, provided you verify hook reachability, enable the packs that match your stack, and accept that it is a policy guard, not a security boundary. This is a source and documentation review as of 2 September 2026.

Key facts at a glance

What dcg is and the problem it targets

The problem is concrete: AI coding agents get shell or CLI access, and occasionally they run a command that destroys hours of uncommitted work or a piece of production state. The repository exists for exactly that failure mode. The README describes dcg as a high-performance hook for AI coding agents that blocks destructive commands before they execute, with examples like git reset --hard, rm -rf, and DROP TABLE users. When a command is blocked, the tool prints the reason and a safer alternative, such as git stash instead of a hard reset.

According to the README, the project began as a Python script by Jeffrey Emanuel and was ported to Rust by Darin Gordon, with the maintainers claiming sub-millisecond latency through SIMD-accelerated filtering, a modular pack system with 50+ security packs, heredoc and inline-script scanning, and context classification that allows grep "rm -rf" while blocking rm -rf /. Those are maintainer claims from the README, not results reproduced in this review.

Agent support is broad on paper: Claude Code, Codex CLI 0.125.0+, Gemini CLI, GitHub Copilot CLI, VS Code Copilot Chat, Cursor IDE, Hermes Agent, Posit Assistant, Oh My Pi, Grok (xAI), Antigravity CLI, and OpenCode are listed, with Aider limited to git hooks and Continue to detection only. Codex CLI received first-class handling: the installer merges a PreToolUse Bash hook into ~/.codex/hooks.json, preserves coexisting hooks, and refuses to overwrite malformed JSON. Support depth clearly varies by agent, so verify yours before relying on it.

Default protection is narrower than the marketing suggests. With no config file, only core.filesystem (recursive removal and equivalent destruction), core.git (destructive git commands that lose uncommitted work), and system.disk are active, and the first two cannot be disabled. On native Windows, windows.filesystem and windows.system are also on by default. Everything else (databases, Kubernetes, Docker, AWS/GCP/Azure, Terraform, storage, CI/CD, and secrets) is opt-in and inactive until a config file enables it. Out of the box you get protection against the most catastrophic local commands; you do not get database or cloud protection until you configure it.

Who should consider dcg, and who should skip it

Consider dcg if you already let coding agents run shell or CLI commands against repositories and local environments and want a first line of defense against hard resets, history rewrites, and recursive deletes. It also makes sense if you run several agents — Claude Code, Codex CLI, Cursor, Copilot — and want one configured guard across them, or if your agents touch databases, Kubernetes, Docker, or cloud CLIs and you are willing to enable and maintain the corresponding packs. Teams that want dangerous-command scanning in review can use the scan mode the README describes for pre-commit hooks and CI.

Skip it if your agents cannot execute shell commands, or if your shell environment is already sandboxed with no destructive permissions. Skip it if you need a hard security boundary: dcg is a policy guard with deliberate escape hatches. DCG_BYPASS=1 disables all protection for a single invocation, allow-once codes and permanent allowlists exist by design, and issue #378 notes that the default posture on evaluation errors is intentionally fail-open for compatibility. Anything you allowlist runs. And if you cannot accept a custom license — GitHub reports NOASSERTION — without legal review, resolve that before adoption.

Windows and PowerShell teams should test their command patterns before standardizing. Issue #379 reports a 0.14.0 false positive in the Codex hook where a PowerShell backtick newline escape was treated as unparseable POSIX command substitution; the cross-dialect parser is still settling.

What v0.14.0 changed and what the release cadence signals

v0.14.0 was published on 1 September 2026, the day before this review, and its release notes describe “a large false-positive/false-negative wave plus doctor enablement checks.” The maintainers added Databricks CLI rules, scoped heredoc interpreter analysis, and strict git rules that they say end the ls .git/rebase-merge class of false positives. They also fixed an interaction where a home-directory move and a Trash rescue each recommended the command the other denied, a git show <ref>:<path> redirect that could overwrite the shown file, git apply patch heredocs, and dashed-builtin spellings like git-push --force.

The most operationally relevant change is dcg doctor. It now verifies that the gate is reachable, not merely installed. For Codex it distinguishes Enabled, never-approved, Disabled, and NotRegistered states in the hooks and trust configuration, and --fix only flips enabled = true on an existing entry; it does not forge a trust entry. For OpenCode it byte-compares the installed plugin against canonical source, so an edited or stubbed plugin shows as outdated or modified.

What the cadence signals: the project is actively maintained and ships often, and the maintainers are iterating on parser edge cases. The same history is a caution. Several recent releases were corrections to false positives and false negatives, and open issues #377 and #379 show similar edges still exist. Pin a version, read the changelog, and re-test on upgrade.

What to check before production

1. Hook reachability, not installation. After install, run dcg doctor and confirm each agent’s hook actually fires. A present-but-never-approved Codex hook is exactly the gap the doctor now surfaces.
2. Pack coverage against your stack. List the CLIs your agents touch, then map them to packs: database, kubernetes, containers, cloud, terraform, storage, secrets, CI/CD. Only core git, filesystem, and disk (plus Windows packs on Windows) are on with no config; dcg init writes a starter config enabling database.postgresql and containers.docker as examples, which is not the no-config default.
3. Bypass and exception policy. Decide who may use DCG_BYPASS=1, how allow-once codes are minted and expired, and what permanent allowlists are acceptable. Issue #378 reports that in 0.13.9 hook-mode testing, allow-once codes were created reusable until expiry, and the fail-open posture on evaluation errors is intentional. Decide before an incident what happens when the guard cannot parse a command.
4. Version pinning and update testing. The installers support pinned versions, for example PowerShell -Version, and the README describes SHA256, minisign, and Sigstore/cosign verification when the tools are available. Test upgrades against a saved corpus of typical commands.
5. License review. The GitHub API reports the license as NOASSERTION and the README labels it custom. Have it reviewed before bundling or relying on it in a business product.
6. A real command corpus. Run your team’s actual command shapes through dcg test and dcg explain, and read the rule ID behind every allow or deny. As the issue reports show, a verdict alone can hide which rule fired.

Known limitations and open edge cases

• Issue #377 (v0.13.9): backtick command substitution in an unquoted heredoc body was allowed while the identical $( ) spelling was denied — a false negative. The reporter did not test main, and v0.14.0 claims heredoc scoping fixes, so verify against the current release.
• Issue #379 (v0.14.0): on Windows, a PowerShell double-quoted `n newline escape was treated as unparseable POSIX command substitution in the Codex hook and denied — a false positive, with a documented non-destructive workaround pipeline.
• Issue #358: native Reasonix support is requested but not implemented.
• Issue #378: opt-in caller attribution and true single-use allow-once grants are requested; audit and exception semantics are still maturing.

In practice, an allow verdict means “not matched by the enabled rules,” not “safe.” dcg evaluates commands against patterns with dialect parsing that is still being corrected, so an allow can change with a version upgrade.

Alternatives and evaluation questions

dcg is one layer, not the whole control. Built-in approval flows in agent tools, sandboxed containers or VMs, least-privilege credentials and read-only service accounts, backups and git reflog, and CI scanning all reduce the same risk. dcg complements those controls best when agents must legitimately run broad commands and you want a fast deny layer with explanations.

Before committing, answer these:

• Which agents and versions does your team use, and does the documented hook support cover them?
• Can you verify, via dcg doctor, that every hook is reachable in your environment?
• Do the default packs match your risk, or do you need database, cloud, Kubernetes, or storage packs enabled and maintained?
• Who may bypass the guard, and how do you audit allowlists and allow-once usage?
• Can you build a command corpus and test it against each release before rollout?
• Has the custom license been reviewed for your use?

Verdict

If your coding agents already execute shell commands, dcg is worth a structured evaluation. It targets a real failure mode, gives you sensible default protection for the most catastrophic local commands, and its diagnostics are aimed at the gap that normally sinks this kind of tool: a hook that is installed but never fires.

The conditions are equally clear. It is a policy guard with documented bypasses, not a security boundary. Most packs relevant to databases and cloud are opt-in. Recent releases were largely corrections to parser edge cases, and open issues show more edges remain. The license is custom and needs review. Teams with audit-grade requirements (single-use exceptions, caller attribution, provable fail-open or fail-closed behavior) should expect to configure, test, and possibly extend the tool rather than treat it as turnkey.

Sources

• Destructive Command Guard repository and README
• dcg v0.14.0 release notes
• Issue #377: backtick heredoc false negative (v0.13.9)
• Issue #379: PowerShell backtick false positive (v0.14.0)

How I can help

If you are evaluating dcg for your team, the practical next step is a configuration and deployment review rather than another pass over the README. I can inspect your agent setup, map dcg’s packs to the CLIs and environments your agents actually touch, verify hook reachability, and build a pre-production checklist with a saved command corpus and an explicit bypass and allowlist policy. To start, I need access to the environment or a representative list of the commands your agents are allowed to run, plus your tolerance for false positives versus missed destructive commands. That configuration and integration work falls under my custom software development services; if your requirements go beyond what dcg offers today (true single-use exceptions, caller attribution, or a custom agent harness integration), that is custom development I can scope during the evaluation. Contact me and we can start with the checklist above.