You give an AI coding agent access to your shell. Most of the time it does something useful: runs a test, lints a file, creates a branch. Sometimes it does something catastrophically stupid. Like git reset --hard HEAD~5 on a repo with three hours of uncommitted work. Or rm -rf ./src because it thought it was cleaning up build artifacts. Or DROP TABLE users on your development database because it was "helping" with a migration.
I have watched agents do all of these things. Not hallucinated scenarios; real logs from real sessions. The agents are good at writing code and bad at knowing when a command is destructive. They do not think twice because they do not think once.
A tool called dcg (Destructive Command Guard) tries to fix this. It is a hook that sits between your AI agent and your shell, intercepts commands that would destroy work, and blocks them before they run. It racked up 1,295 stars on GitHub in a single day this week and now sits at over 4,500 stars total. People clearly have this problem.
What it actually does
dcg installs as a pre-execution hook for whatever AI coding agent you use. It supports Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, VS Code Copilot Chat, Cursor, Hermes Agent, Grok's CLI, and a few others. The installer detects which agents you have and configures the hook for each one.
When the agent tries to run a command, dcg scans it first. If the command matches a destructive pattern, dcg blocks it, prints a human-readable explanation on stderr, and suggests a safer alternative. The agent sees a clean rejection on stdout and has to try something else.
Here is what happens when an agent tries 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.That is it. The command never runs. Your work is still there.
Why it matters now
Six months ago, most people were using AI coding assistants for autocomplete and single-function generation. The agent would suggest code; you would review it; you would run the commands yourself. The agent never touched your shell.
That has changed. Claude Code, Codex CLI, Gemini CLI, and the rest all run commands directly now. You give them a task and they execute it: git checkout, npm install, cargo build, psql -c "...". This is convenient and also terrifying. The agent does not have the context to know that git clean -fdx will wipe your untracked files, or that docker system prune -a --volumes will delete every volume including the one your database uses.
I have talked to developers who lost hours of work this way. One person told me their agent ran rm -rf node_modules .next to "clean the build cache" and also deleted a directory called .next-staging that contained work they had not committed yet. The agent did nothing wrong by its own logic. The command was reasonable. The filename collision was the problem, and the agent had no way to know.
How the detection works
The tool uses a "pack" system. Each pack is a set of rules for a specific category of destructive commands. The core packs are on by default with no configuration: filesystem operations (rm -rf outside temp directories) and git operations that lose uncommitted work or rewrite history. These cannot be disabled.
Everything else is opt-in. You enable packs for databases, Kubernetes, Docker, AWS, GCP, Azure, Terraform, Ansible, and about 45 other categories. If you work with PostgreSQL, you turn on database.postgresql and dcg blocks DROP DATABASE, TRUNCATE, and dropdb. If you use Kubernetes, kubernetes.kubectl blocks kubectl delete namespace and mass deletion commands.
One detail I appreciate: dcg can tell the difference between a command that references a dangerous pattern and one that executes it. grep "rm -rf" *.sh is data. rm -rf / is execution. The tool blocks the second and lets the first through. This sounds obvious but if you have ever dealt with a naive regex-based shell filter, you know it is not. Most of them just pattern-match and block everything containing the string rm, which breaks npm run, format, and anything with "remove" in the path.
It also scans heredocs and inline scripts. python -c "os.remove('/important/file')" gets caught the same way a standalone rm would. This matters because agents love to embed destructive operations inside Python one-liners and shell scripts.
Performance and the fail-open question
dcg is written in Rust. The README claims sub-millisecond latency using SIMD-accelerated filtering. I have not benchmarked it myself, but the architecture makes sense: regex patterns are lazily compiled and cached, and the hot path is pattern matching against an in-memory rule set. For a hook that runs on every single command an agent executes, latency is the whole game. If it adds 50ms per command, people will disable it. At sub-millisecond, the overhead is invisible.
The tool is designed to fail open. If dcg times out, encounters a parse error, or hits any internal problem, it lets the command through rather than blocking it. This is the right call for a safety layer. A guard that breaks your workflow when it gets confused is worse than no guard, because people will remove it entirely after the third false block. Better to let one dangerous command through occasionally than to make the tool unusable.
That said, fail-open has its own risks. If the tool fails silently and lets through the one command that would have destroyed your repo, you will not know until it is too late. There is no perfect answer here. The tool also has an escape hatch: DCG_BYPASS=1 as an environment variable disables all protection for a single command. Useful when you genuinely need to run git reset --hard and dcg keeps blocking you.
The trust model for different agents
One thing I found interesting is the per-agent trust configuration. You can set different rules for different agents. For Claude Code, which is relatively conservative, you might enable a wider allowlist and disable the Kubernetes pack because Claude does not touch your cluster. For an unknown agent, you can set trust_level = "low", add extra rule packs, and disable all allowlist bypasses.
This is a good approach because not all agents are equally reckless. The ones that have been around longer and have more guardrails built in (Claude Code, for example) can be given more freedom. Experimental agents or ones you are trying for the first time get locked down. The trust level is advisory, not magic; it does not change rule evaluation directly. The behavioral differences come from the pack and allowlist settings you define in each agent profile.
What I would like to see next
The tool is solid for what it covers, but there are gaps. The biggest one is that it only blocks commands. It does not log them persistently or alert you after the fact. If an agent runs a destructive command and dcg blocks it, you see the rejection in your terminal output and that is it. There is no audit trail. For teams running agents in CI or shared environments, a log of blocked commands would be valuable. You want to know if your agent is repeatedly trying to run rm -rf even if dcg keeps stopping it.
The pack system is broad but the coverage depends on you knowing which packs to enable. A fresh install with no config file only blocks filesystem and git destruction. Everything else, including database operations, is off until you explicitly turn it on. I understand the reasoning (do not surprise users with blocks on commands they need), but I suspect most people will install dcg, see it working, and never bother to enable the database or cloud packs. A guided setup that asks "what do you work with?" and enables relevant packs would help.
The Codex CLI integration is new enough that it deserves a mention. dcg treats Codex as a first-class target now, not just through Claude compatibility. Codex rejects unknown fields in hook output, so dcg detects Codex payloads and emits only the fields Codex expects. Small detail, but the kind of thing that makes the difference between "it works" and "it works reliably."
Should you use it
If you use any AI coding agent with shell access, yes. The install takes about 30 seconds. The default packs cover the two most common ways agents destroy work: git history rewrites and filesystem deletion. The overhead is invisible. The worst case is that it blocks a command you actually wanted, and you either use the bypass or add it to the allowlist.
I have been running agents without a guard like this for months and gotten lucky. The one time I was not lucky, an agent ran git checkout . after a failed merge and wiped about 90 minutes of changes that were not committed yet. I recovered most of it from editor history. It was enough of a scare that I now have dcg installed on every machine where I use Claude Code or Codex.
4,500 stars in six months for a command-blocking hook tells you something about the state of AI coding agents. The tools are powerful and useful and also capable of destroying your work in ways no human developer ever would. A safety layer is not optional anymore. It is the cost of giving an AI agent access to your shell.