dcg (Destructive Command Guard): a pre-execution hook for AI coding agents

The failure mode dcg is built around

The problem is not that agents are malicious. It is that an agent with shell access can run a command whose blast radius is much larger than the task it was given. The README names the canonical cases: git reset --hard, rm -rf ./src, and DROP TABLE users. Each of those is a single line, each is plausible as a step toward a legitimate goal, and each can destroy work that was never committed. The audience is anyone who has handed a terminal to Claude Code, Codex CLI, Gemini CLI, Copilot CLI, Cursor, or one of the other agents listed in the README, and who has uncommitted changes in the working tree. That is a narrower audience than "all developers", and it is the right one. If your agent runs in a container with no mounted volumes and no credentials, the value drops sharply, because there is little to destroy.

How the hook intercepts a command

dcg is not a wrapper around git and it is not a shell alias. It registers as a hook in the agent's own configuration, so the agent calls dcg before executing a tool call, and dcg returns a decision. The README describes the split explicitly: machine-readable hook output goes to stdout, while the human-readable denial panel goes to stderr. The example denial shows a bordered panel with a Reason line ("git reset --hard destroys uncommitted changes"), the Command, and a Tip suggesting git stash first. That stream separation matters because agents parse stdout and humans read stderr; putting the pretty panel on stdout would risk breaking the client's parsing.

Detection is pattern-based against the command string, with two refinements the README calls out. First, context detection: grep "rm -rf" is treated as data and allowed, while rm -rf / is treated as execution and blocked. Second, heredoc and inline script scanning, which catches python -c "os.remove(...)" and embedded shell scripts that would otherwise slip past a naive prefix match. The README also mentions SIMD-accelerated filtering and sub-millisecond latency, and a bounded failure policy where analysis timeouts become an explicit review or block outcome rather than a silent pass. The latency figure is the project's own claim.

Installing it and wiring up an agent

The README gives a one-line installer for Linux and macOS (and Windows via WSL):

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

The README states the script auto-detects the platform, downloads the matching binary, and configures supported agent hooks. For native Windows there is a separate PowerShell path that installs dcg.exe, verifies a mandatory SHA256 checksum, optionally verifies a minisign signature and Sigstore/cosign provenance, adds dcg to the User PATH, and runs a self-test with -Verify. Not every integration is automatic. OpenCode needs dcg install --opencode, Oh My Pi needs dcg install --omp, Crush needs dcg install --crush, and Antigravity CLI needs dcg install --agy. Grok can use a native ~/.grok/hooks/dcg.json via dcg install --grok, or fall through the Claude compatibility layer. Two entries in the supported list are qualified in the README itself: Aider is "limited, git hooks only", and Continue is "detection only". Treat those two as out of scope for real protection.

The pack system and config.toml

Out of the box dcg blocks dangerous git and filesystem commands. Beyond that, dcg ships packs. The README claims 50+ packs covering databases, Kubernetes, Docker, AWS, GCP, Azure, and Terraform. On Windows, the windows.filesystem and windows.system packs are on by default, so del /s, rd /s, Remove-Item -Recurse (with or without -Force), format, and vssadmin delete shadows are blocked without configuration. The README also documents dcg explain "command", which prints why a given command would be blocked. That is the fastest way to check whether a pack is actually active before you rely on it.

Where the protection does not reach

The hook model is the limitation. dcg only sees commands that the agent routes through it. If an agent shells out in a way the client does not report as a tool call, or if you run the same destructive command yourself in a terminal, dcg is not in the path and does nothing. The README's own supported list carries two soft entries (Aider with git hooks only, Continue with detection only), which is an admission that integration depth varies by client. The bounded failure policy is a second edge: the README says analysis timeouts become explicit review or block outcomes, and that malformed raw hook envelopes remain auditable and configurable. Whether a timeout blocks or asks for review is a configuration decision, and the wrong setting in an unattended CI job either halts the pipeline or lets the command through. Finally, the licence is listed as NOASSERTION on GitHub. That is not a standard SPDX identifier. I cannot tell you what it permits, and you should read the LICENSE file before adopting dcg in a commercial or redistributed product.

How this differs from git hooks and from sandboxing

The obvious alternative is a git pre-commit or pre-push hook that rejects dangerous content, and the difference is timing and scope. A git hook fires on a git operation and inspects what is being committed; it cannot stop rm -rf ./src, and it cannot stop a command before the agent runs it. dcg fires earlier, on the command itself, and covers non-git tools. The other alternative is sandboxing the agent (a container, a VM, a restricted user), which is a stronger guarantee: a sandboxed agent cannot delete what it cannot see. The trade-off is setup cost and friction, since the agent loses access to the host toolchain, credentials, and files you may want it to work on. dcg and a sandbox are not substitutes. A sandbox bounds the damage; dcg prevents a specific class of mistake from happening at all, at the cost of depending on the agent's hook contract.

Maintenance cost and version pinning

dcg ships frequently. The repository shows v0.15.2 on 2026-10-01, v0.15.3 on 2026-10-08 and v0.16.0 on 2026-11-01, and the last push on 2026-11-02 is close to the v0.16.0 release. That cadence is normal for a tool that tracks a moving set of agent clients, and it also means your hook configuration can break when a client changes its hook schema. The install script fetches from the main branch by default, which pulls whatever is current at install time; the Windows installer supports -Version vX.Y.Z to pin, and -RequireMinisign to fail closed if the signature sidecar or verifier is unavailable. If you install on Linux, note that the curl line in the README appends ?$(date +%s) to defeat caching, which guarantees you get the newest script on every run. That is convenient and also means you are executing unpinned remote code as part of setup. Pinning the binary version and verifying the checksum is the only way to make the install reproducible.

Who should install it, and what to check first

Install dcg if you run a supported agent on a machine with uncommitted work and you want a layer that blocks dangerous git and filesystem commands out of the box. The zero-config git and filesystem coverage is the part that pays for itself, and dcg explain gives you a way to confirm what is active before you trust it. Skip it if your agent already runs inside a disposable sandbox, or if you use Aider or Continue and expect the same coverage as Claude Code, since the README itself qualifies those integrations. Before rolling it out, confirm three things: that your agent version is in the supported list (Codex CLI needs 0.125.0 or later per the README), that the hook actually fires after install by triggering a known-blocked command, and that the LICENSE file grants the rights your organisation needs. The conclusion is not that dcg replaces careful review. It is that dcg closes one specific gap, the gap between an agent deciding to run git reset --hard and that command executing, and it does so only for the clients it is wired into.

Editorial conclusion

Adopt dcg if you already run a supported agent and want a layer that blocks dangerous git and filesystem commands out of the box, especially on machines holding uncommitted work. Do not adopt it as your only safety net: anything that bypasses the hook (a shell the agent spawns outside the configured path, a non-supported tool) is unprotected, and the licence is NOASSERTION on GitHub, so read LICENSE before shipping it into a commercial workflow. Verify first that your agent version appears in the supported list and that the hook fires after install; the README states Codex CLI needs 0.125.0 or later.

Frequently asked questions

Official sources

1. Dicklesworthstone/destructive_command_guard on GitHub
2. Issues
3. README
4. Releases