dcg (Destructive Command Guard): a pre-execution hook that blocks destructive git and shell commands

The failure dcg exists to prevent

An AI coding agent with shell access is an agent that can run git reset --hard. The README's own framing is that agents occasionally run catastrophic commands such as git reset --hard, rm -rf ./src or DROP TABLE users, destroying hours of uncommitted work in seconds. That is the entire problem statement, and it is a narrow one. dcg is not a sandbox, not a permission system and not a container. It is a hook that inspects a command an agent is about to execute and decides whether to let it through.

The intended user is someone running a coding agent in a working directory that contains work they have not committed. If you commit constantly and push, the blast radius of a bad agent command is small and dcg's value drops accordingly. If you let an agent refactor a large tree while you are away from the keyboard, the value is obvious. The README lists 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, Oh My Pi, Crush and Pi as supported integrations, with Aider limited to git hooks and Continue listed as detection only. That last distinction matters: detection is not blocking.

How the hook decides: packs, context detection and stream separation

dcg is a Rust binary built from a Cargo package named destructive_command_guard, with a single binary named dcg. The dependency list in Cargo.toml describes the matching engine: aho-corasick for multi-pattern string matching used as a keyword quick-reject, regex and fancy-regex for the rule patterns, memchr for fast scanning, and shell-words for quote-aware tokenization used in static stdin data-flow analysis. That combination points at a design where most commands are rejected cheaply by keyword before any expensive pattern matching happens, which is where the README's sub-millisecond latency claim comes from. The README does not publish the benchmark methodology behind that claim.

The rule set is organised into packs. The README describes 50+ security packs spanning databases, Kubernetes, Docker and AWS/GCP/Azure and Terraform, and shows a config.toml where packs such as database.postgresql, kubernetes.kubectl, cloud.aws and containers.docker are enabled by name. External packs are parsed from YAML, and config.schema.json exists so editors can autocomplete and validate the TOML.

The part worth understanding is context detection. The README states dcg will not block grep "rm -rf" because that is data, but will block rm -rf / because that is execution. Getting that distinction right is the difference between a tool people keep and a tool people uninstall after the third false positive. dcg also scans heredocs and inline scripts, so python -c with an os.remove call inside is inspected rather than passed through. Output is split deliberately: machine-readable hook output goes to stdout while the human-readable denial panel, rule context and suggestions go to stderr. That separation is what lets an agent parse a denial while a human sees an explanation.

Installing dcg and confirming it actually blocks something

The README's quick install is a shell one-liner that auto-detects the platform, downloads the matching binary and configures detected agent hooks. It targets Linux, macOS and Windows via WSL.

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

On native Windows the README points at a PowerShell installer instead, which installs dcg.exe, verifies a mandatory SHA256 checksum, verifies the release's minisign signature when minisign is available, and verifies Sigstore/cosign provenance when cosign and a trusted bundle are available. It adds dcg to the User PATH under -EasyMode and runs a self-test under -Verify.

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

The first real use is not to install it and hope. It is to ask it why it would block something. The README documents an explain mode, and this is the command to run before you trust the hook with an unattended agent.

dcg explain "command"

According to the README, that command shows exactly why something is blocked. You should see the matching rule and its reasoning rather than a bare refusal. If a command you consider dangerous comes back as allowed, you have found the boundary of the default rule set before it costs you anything.

The second step is widening coverage, because the default configuration is git and filesystem protection. Database, Kubernetes, Docker and cloud rules are opt-in. The README gives this example for ~/.config/dcg/config.toml.

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

On Windows the README notes that 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 out of the box. That is a platform-specific default worth knowing if you move between operating systems.

Where dcg stops protecting you

The honest limitation is in the mechanism. dcg matches commands against patterns. A destructive operation that does not resemble any pattern in the enabled packs will execute. An agent that writes a small script to a file and then runs that file is one step removed from the command text dcg inspects, and the README's heredoc and inline-script scanning addresses the inline case, not the write-then-execute case.

The second limitation is configuration drift in the other direction. Enabling the cloud.aws pack means aws ec2 terminate-instances is blocked. That is correct when the agent is working on application code and wrong when the agent's actual task is infrastructure teardown. A blocked command is a stopped agent, and the README's own example suggests git stash as the alternative to a hard reset, which is a reasonable suggestion and also a decision the agent may not be able to make on its own.

The third is coverage asymmetry across agents. The README is explicit that Aider support is limited to git hooks only and Continue is detection only. If your workflow is built on either, dcg is not a blocking layer for you regardless of what the feature list suggests.

Finally, the failure policy is bounded rather than silent. The README describes analysis timeouts as becoming explicit review or block outcomes, and malformed raw hook envelopes as remaining auditable and configurable. That is a deliberate choice to fail toward visibility, but it means a timeout can surface as a block, and a blocked agent is a stalled agent. The README does not document what the default timeout value is.

dcg versus a real sandbox

The alternative most teams reach for is process isolation: run the agent in a container, a VM, or an OS-level sandbox with a read-only mount of anything you cannot afford to lose. That approach does not care what the command text says. rm -rf on a read-only mount fails because the filesystem refuses it, not because a pattern matched. It is strictly stronger against unknown commands and strictly weaker at explaining itself, since the agent gets a filesystem error rather than a denial panel with a suggested alternative.

The two are complementary rather than competing. A sandbox bounds the damage; dcg prevents the attempt and tells the agent what to do instead, which keeps the agent productive rather than stuck. If you can only do one, and your threat model is a well-behaved agent making an occasional bad decision, dcg's explanation output is the more useful signal. If your threat model includes an agent doing something nobody anticipated, isolation is the only thing that holds.

Within the hook category, dcg's differentiator is breadth of agent integrations combined with pack-based rules. A hand-written hook in a single agent's config format gets you one agent and whatever rules you write yourself. dcg's install command configures many agents at once, and the packs are maintained upstream rather than by you.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-09, with releases v0.14.0 on 2026-09-01, v0.14.1 on 2026-09-08 and v0.14.2 on 2026-09-09. Cargo.toml in the repository lists version 0.14.3, so the working tree is ahead of the most recent tagged release. The release cadence over that window is roughly weekly, which is fast enough that pinning matters.

Both installers support pinning. The PowerShell installer takes -Version vX.Y.Z, and the README documents -RequireMinisign to fail closed if the sidecar or verifier is unavailable. The shell installer's --easy-mode flag is shown in the quick install; the README does not document an equivalent pinning flag for it in the text available here, so verify that before relying on it in a managed environment.

Upgrade cost is mostly rule churn. A new release can add patterns that block commands your agent previously ran, which shows up as a sudden denial in a workflow that was fine yesterday. That is the point of the tool, but it means an upgrade is a behaviour change and not just a binary swap. The config.schema.json file is there so your editor flags invalid keys in config.toml when the schema changes.

The licence is the part to check yourself. Cargo.toml declares license-file = "LICENSE" rather than an SPDX identifier, the repository's licence badge reads custom, and the GitHub metadata reports NOASSERTION. That combination means the terms are whatever the LICENSE file says and are not a standard licence a tool can classify. Read it before shipping dcg inside a product or a managed fleet. Nothing here is legal advice.

Editorial conclusion

Adopt dcg if you run an AI coding agent unattended in a repository with uncommitted work, and you accept that its protection is pattern-based rather than a sandbox. Do not adopt it as a substitute for isolation: a command the rule set has never seen still executes, and the README is explicit that Aider support is limited to git hooks and Continue is detection only. Before trusting it, run dcg explain on three or four commands you consider dangerous and confirm they are actually blocked, and check which packs are enabled in ~/.config/dcg/config.toml, because the default set is git and filesystem, not databases, Kubernetes or cloud APIs.

Frequently asked questions

Official sources

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