I’m going to tell you a short story. Last month, I was working on a Django project, about four hours deep into a refactor. I asked an AI coding assistant to “clean up the branch history” before a PR review. Two seconds later, it ran git reset --hard HEAD~10. Ten commits. Four hours. Gone.
Not malicious. Just a bad interpretation of what I meant.
And that’s the thing about AI coding agents — they’re incredibly useful until they run a command you can’t take back. This week alone, we’ve seen research on HalluSquatting, GhostApproval symlink attacks, and the Sophos report showing AI coding agents triggering endpoint security alerts designed to catch human attackers. The tools we trust to write code can also delete it, destroy it, or leak it — and they’ll do it fast.
That’s where Destructive Command Guard (dcg) comes in. It’s a lightweight, Rust-powered hook that intercepts dangerous commands before they execute, protecting your work from accidental destruction across Claude Code, Codex CLI, Gemini CLI, Copilot, Cursor, and more. Think of it as a seatbelt for your AI agent.
What Exactly Is dcg?
dcg stands for Destructive Command Guard, and it’s exactly what it sounds like — a safety layer between your AI coding agent and your filesystem. Created by Jeffrey Emanuel (ported to Rust by Darin Gordon), it’s an open-source tool (MIT license, 1,700+ stars on GitHub) sitting at the intersection of developer productivity and AI safety.
Here’s what it does in practice:
- Blocks dangerous git commands like
git reset --hard,git branch -D, andgit push --force - Intercepts destructive filesystem commands like
rm -rf ./srcandmvoperations on critical files - Scans heredocs and inline scripts — so
python -c "os.remove(...)"doesn’t slip through - Comes with 50+ security packs covering databases, Kubernetes, Docker, AWS, GCP, Azure, Terraform, and more
- Runs in under a millisecond — SIMD-accelerated filtering that you won’t notice
The beauty is you don’t have to configure anything to get started. Zero-config protection kicks in immediately after installation. But if you want granular control, the config system is surprisingly powerful.
Installation: One Command, Two Seconds
I tested this on WSL (Windows Subsystem for Linux) and macOS — both worked without a hitch. The installer auto-detects your platform, downloads the right binary, and hooks into every AI coding agent it finds on your system.
Linux, macOS, and WSL:
curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh" | bash -s -- --easy-modeWindows (native PowerShell):
& ([scriptblock]::Create((irm "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.ps1"))) -EasyMode -VerifyThe --easy-mode flag adds dcg to your PATH, runs a self-test, and configures hooks for every supported agent it detects — Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, Cursor IDE, Hermes Agent, and Grok. For Copilot specifically, hooks are repo-local, so run the installer from each project you want to protect (or use --easy-mode to handle it globally).
That’s it. No package managers to set up, no dependency hell. The binary is compiled Rust — about 11MB on disk.
Testing It: The Satisfying Part
Once installed, try running something dangerous through your AI agent of choice. Ask your assistant to “force delete the current branch and reset to origin/main.” Here’s what happens:
$ git reset --hard HEAD~5
════════════════════════════════════════════════════════════════
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.
════════════════════════════════════════════════════════════════I’ll be honest — watching that message appear after weeks of secretly worrying about agent-induced disasters is genuinely satisfying. dcg prints the block reason, the exact command that was intercepted, and a safer alternative. The output is split across stdout (machine-readable JSON for the agent) and stderr (the human-readable panel), so your AI assistant knows the command was blocked, and you see exactly why.
You can also test it from your own terminal without an agent:
dcg check "rm -rf /home/project"This runs the command through dcg’s rule engine and shows you which pack flagged it, what rule matched, and whether the command would be blocked if executed through an agent hook.
Enabling the Heavy-Duty Packs
The default installation blocks the most common destructive git and filesystem commands. But if you work with databases, containers, or cloud infrastructure, you’ll want to enable the specialized packs. Open ~/.config/dcg/config.toml (it’s created on first install) and add:
[packs]
enabled = [
"database.postgresql",
"database.mysql",
"kubernetes.kubectl",
"cloud.aws",
"containers.docker",
"terraform.core",
]Once saved, dcg now intercepts DROP TABLE users, kubectl delete namespace production, aws ec2 terminate-instances, and docker system prune -a — every one of those is a command an AI agent could plausibly run based on a vaguely worded prompt. There are over 50 packs to explore. Run dcg packs --verbose to list every available pack with its description and rule count.
Agent-Specific Profiles: Fine-Tuning Trust
Not all AI agents are created equal. dcg lets you define agent-specific profiles in the config file. For example, I trust Claude Code more than a random unknown agent, so I give it a wider allowlist:
[agents.claude-code]
trust_level = "high"
additional_allowlist = ["npm run build", "cargo test", "python manage.py migrate"]
disabled_packs = ["kubernetes"]
[agents.unknown]
trust_level = "low"
extra_packs = ["paranoid"]
disabled_allowlist = trueThis means Claude can run npm run build and cargo test without dcg intervening, but an unknown agent gets the full paranoia treatment — extra packs, no allowlist bypass. The configuration is hot-reloaded, so you don’t need to restart anything after editing the file.
Escape Hatches: When You Really Need to Run That Command
dcg knows it might overcorrect. If a command you genuinely need is blocked, there are three levels of bypass:
- Single command bypass:
DCG_BYPASS=1 git reset --hard HEAD— disables all protection for that invocation - Allow-once code: Copy the short code from the block message and run
dcg allow-once <code>— the exact command runs one time - Permanent allowlist:
dcg allowlist add core.git:reset-hard -r "I know what I'm doing"— permanently allows a specific rule
I use the allow-once approach most days. It gives me one chance to confirm a command is safe without permanently opening a hole in the guard. You can also temporarily disable the hook entirely by commenting out the dcg entry in ~/.claude/settings.json — but honestly, if you find yourself doing that often, you’re probably fighting the tool instead of letting it protect you.
CI/CD Integration: Scan Mode
Here’s something I didn’t expect — dcg has a scan mode for pre-commit hooks and CI pipelines. It scans staged changes for dangerous command patterns and flags them before they ever reach a production environment:
dcg scan --stagedRun this as a pre-commit hook or in GitHub Actions, and it catches embedded destructive commands in your diffs. For teams where multiple developers use AI coding agents, this is a cheap but effective second line of defense. Combined with npm 12’s new install-script lockdown and supply-chain hygiene practices, it’s another layer in a defense-in-depth approach to agent-assisted development.
The Broader Context: Why This Matters Right Now
This week alone, security researchers published findings on HalluSquatting attacks that trick AI coding assistants into installing botnet malware, GhostApproval symlink vulnerabilities that let malicious repos take over a developer’s machine, and a technique called Ghostcommit that hides prompt injections inside PNG images to steal secrets from AI code reviewers. The supply chain security conversation has expanded from “what open-source packages are you using” to “what commands is your AI agent running on your behalf.”
dcg won’t solve all of those problems. It’s a guardrail, not a firewall. But having used it for a week across Claude Code and Codex CLI, I can tell you it catches the stuff that keeps me up at night — the accidental destructive operation, the misread prompt, the variable interpolation that expands to rm -rf / instead of rm -rf ./temp.
And the performance penalty? I measured it. On a typical session with Claude Code running 200+ tool calls, dcg added less than 200ms of cumulative latency. You genuinely cannot feel it.
Bottom Line
AI coding agents are here to stay, and they’re getting more capable every week. But capability without guardrails is a liability. dcg gives you a practical, low-friction safety net that works with the tools you’re already using — whether that’s Claude Code, Codex CLI, Copilot, or Cursor. And if you’re thinking about which AI tools to trust with your infrastructure, you might also want to read about why Fortune 500 companies are quietly moving their AI workloads in-house.
The install takes two seconds. The peace of mind lasts as long as you’re coding. Try it, configure your packs, and sleep better knowing your Friday afternoon refactor won’t disappear into a git reset --hard black hole.