Update — July 16, 2026: Tibo (@thsottiaux) confirmed GPT-5.6 Codex deleted user
$HOMEdirectories when full access disabled sandboxing and auto review — hook guards like dcg are necessary but not sufficient without OS isolation. Full chain: Codex $HOME deletion investigation.
Update — August 2, 2026: Fable-OS demonstrates the boundary of command guards: when an agent's tools are kernel syscalls and Driver VM operations rather than shell commands, safety has to come from capability, memory, hardware, and network boundaries—not a Bash hook alone.
AI coding agents are becoming capable enough to work for minutes or hours without constant supervision. That makes the old safety model—read every proposed shell command and click approve—hard to sustain. One mistaken git reset --hard, recursive deletion, database reset, or cloud teardown can erase work much faster than an agent created it.
Destructive Command Guard, usually shortened to dcg, addresses that narrow problem. It installs as a pre-execution hook, inspects commands proposed by coding agents, and denies patterns associated with irreversible damage. The repository had roughly 3,000 GitHub stars when this guide was written and supports Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, Cursor, Hermes Agent, Grok, and related tools.
The useful question is not whether dcg has a long list of patterns. It is whether you can depend on it when a command is genuinely dangerous. This guide covers the installation path, matching architecture, default protections, current Codex caveat, and the security layers dcg does not replace.
TL;DR: should you install Destructive Command Guard?
| Question | Direct answer |
|---|---|
| What does dcg do? | It evaluates proposed shell commands before an AI coding agent executes them and blocks recognized destructive patterns. |
| Is it a sandbox? | No. It is a command guard. Pair it with a sandbox, least-privilege credentials, backups, and Git checkpoints. |
| What is protected by default? | Destructive Git operations, dangerous recursive filesystem deletion, and major disk-destruction commands; Windows adds two native protection packs. |
| Are database and cloud commands blocked automatically? | Usually not. PostgreSQL, Docker, Kubernetes, AWS, Railway, Stripe, and many other categories are opt-in packs. |
| Does it understand context? | Yes. It distinguishes executable spans from comments and data, and it can inspect heredocs and inline scripts. |
| Can it miss a command? | Yes. Unknown patterns, direct non-shell mutations, invoked scripts, timeouts, parser failures, or a missing hook can pass through. |
| Does Codex work? | Codex CLI 0.125.0+ is supported, but verify a real block. The project documented a Windows fail-open bug in v0.6.5 and a v0.6.6 protocol fix. |
| What did we verify? | The published macOS v0.6.5 binary blocked git reset --hard HEAD~1 and allowed git status in direct dcg test runs. |
What Destructive Command Guard actually does
dcg sits in the agent tool lifecycle. Before a supported coding agent runs a shell command, its PreToolUse or equivalent hook sends a JSON payload to the dcg binary. dcg extracts the command, normalizes it, checks allow rules and enabled protection packs, then returns either an allow or deny response in the protocol that agent expects.
That placement matters. A warning printed after rm -rf finishes is worthless. A pre-execution hook can stop the call before the shell receives it.
If you already understand Claude Code hooks, dcg is a productionized version of the “inspect every Bash call” pattern. Instead of maintaining a brittle grep one-liner, you get named rules, context classification, configurable packs, allow-once exceptions, CI scanning, explanations, agent-specific protocols, and a Rust binary designed to run on every command without adding noticeable latency.
The project describes its purpose in one sentence: it blocks destructive commands “before they execute.” That is the correct boundary to remember. dcg is not evaluating whether the agent’s overall plan is good, whether generated code is secure, or whether a safe-looking command has a buggy implementation. It is enforcing a command policy at one specific gate.
The command path
agent proposes Bash command
↓
agent invokes PreToolUse hook
↓
dcg parses and classifies command
↓
safe rule → allow
deny rule → return protocol-specific block
no match or analysis failure → allow by default
The final line is as important as the denial path: dcg intentionally defaults to allowing commands it does not recognize and usually fails open if analysis cannot finish safely.
What we verified with the published binary
We downloaded the official aarch64-apple-darwin archive for the currently published v0.6.5 release into a temporary directory. We did not install hooks or modify user configuration; we invoked the binary’s test mode directly.
First, the version output identified the expected build:
dcg v0.6.5
Built: 2026-07-03
Target: aarch64-apple-darwin
Then we tested a destructive Git command without executing it:
dcg test --no-color "git reset --hard HEAD~1"
The command returned exit code 1, identified core.git:reset-hard, explained that the operation would discard staged and working-tree changes, and suggested safer alternatives such as git stash, git reset --soft, and reviewing git diff first.
A safe command behaved differently:
dcg test --no-color "git status"
That returned exit code 0 with Result: ALLOWED.
This is a useful smoke test, not proof of universal protection. It verifies that the packaged macOS binary and core Git matcher behave as documented for two known inputs. It does not prove that the hook is registered in your agent, that every command shape is covered, or that a different agent protocol will enforce the returned denial.
How to install dcg without trusting it blindly
The project’s easy-mode installer downloads a prebuilt binary, verifies its checksum, detects supported agents, and merges hook configuration where possible:
curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" \
| bash -s -- --easy-mode
On native Windows, the repository provides a PowerShell installer:
& ([scriptblock]::Create((irm "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.ps1"))) -EasyMode -Verify
Piping a remote script into a shell is convenient, but it is still code execution. For a higher-assurance installation, read install.sh or install.ps1, pin a release, download the correct archive, verify its checksum, and only then run the binary.
After installation, do not stop at dcg --version. Verify all three layers:
- Binary:
dcg --versionreturns the version and target you expect. - Policy:
dcg test "git reset --hard HEAD~1"reports a block. - Agent hook: ask the actual agent, inside a disposable repository, to propose a harmlessly testable command that dcg should deny; confirm the tool is reported as blocked, not merely “hook failed.”
The third check catches the most dangerous failure mode: a perfectly functional matcher connected to an agent through the wrong response protocol.
What does dcg block by default?
The repository includes more than 50 modular protection packs, but most are not enabled automatically. With no config file, the Unix defaults focus on catastrophic local damage:
| Pack | Default status | Representative protection |
|---|---|---|
core.filesystem | Always on | Dangerous rm -rf outside temporary directories |
core.git | Always on | Hard resets, destructive restores, force pushes, forced branch deletion, stash destruction |
system.disk | On by default | mkfs, disk-targeting dd, partition and LVM removal operations |
windows.filesystem | Default on Windows | Recursive del, rd, forced PowerShell deletion, formatting |
windows.system | Default on Windows | Shadow-copy deletion, diskpart, destructive volume and boot operations |
Database, container, Kubernetes, cloud, DNS, payment, monitoring, backup, CI/CD, and platform packs are generally opt-in. This conservative default reduces surprise blocks, but it also means installing dcg does not automatically protect a production database or cloud account.
To enable additional categories, create ~/.config/dcg/config.toml:
[packs]
enabled = [
"database.postgresql",
"database.redis",
"containers.docker",
"kubernetes.kubectl",
"cloud.aws",
"infrastructure.terraform",
"platform.github",
"platform.railway",
"payment.stripe"
]
This pack model is better than turning on every rule globally. A frontend developer working locally has a different risk surface from an infrastructure agent with access to AWS, Kubernetes, Terraform, and production credentials. Enable packs that correspond to capabilities the agent can actually reach.
How dcg avoids blocking documentation and search commands
A naive blacklist sees the string git reset --hard and panics everywhere. That creates false positives when the string appears in documentation, a grep query, a comment, test data, or quoted prose.
dcg uses context classification to separate spans that will execute from spans that are likely data. It distinguishes command words, inline code passed through flags such as bash -c, quoted arguments, heredoc bodies, comments, and unknown regions. Known-safe patterns are checked before destructive patterns.
These two inputs should not receive the same decision:
grep "git reset --hard" safety-guide.md
git reset --hard HEAD~1
The first searches for text. The second changes repository state. The context-aware approach is why dcg can cover more than exact top-level commands without making normal documentation work unbearable.
For heredocs and inline programs, the tool uses a bounded three-stage pipeline:
- A fast trigger detects heredoc or interpreter patterns.
- A bounded extractor isolates the executable body.
- Language-aware analysis and fallback patterns look for destructive operations.
Commands that do not contain relevant keywords can skip expensive matching. Patterns compatible with Rust’s linear regex engine receive predictable matching; advanced expressions can fall back to a backtracking engine. The project enforces performance budgets because this hook runs before every shell command.
That sophistication reduces false positives. It does not eliminate them. The open issue tracker has included reports around inert heredoc prose, pack suggestions, installer paths, and agent protocol integrations. Treat the issue tracker as operational documentation, not merely a backlog.
The Codex v0.6.5 and v0.6.6 caveat
The most instructive dcg incident is GitHub issue #183. A Windows user running dcg v0.6.5 with Codex CLI 0.144.1 found that dcg detected dangerous commands, but Codex classified the hook response as a failure and then executed the command because the hook path failed open.
The pattern engine was not the problem. The response contract was.
The project’s main-branch changelog documents a v0.6.6 fix: Codex denials use a minimal hookSpecificOutput JSON object on stdout and exit 0, while the rich explanation remains on stderr. The Codex integration reference explains that extra fields can cause Codex’s strict parser to turn a policy denial into a failed hook.
There is a release-timing wrinkle as of July 13, 2026. The repository’s main branch documents v0.6.6, but GitHub’s visible published release list and release API still identify v0.6.5 as the latest downloadable release during our check. Before relying on Codex protection—especially on Windows—run:
dcg --version
If you have v0.6.5, do not assume the v0.6.6 protocol fix is present merely because the README or changelog describes it. Wait for the v0.6.6 asset to be published, install a maintainer-approved fixed build, or inspect and build the corrected source yourself. Then test the complete agent-to-hook path in a disposable repository.
This incident is not a reason to dismiss dcg. It is a reason to understand security controls as systems. Detection, serialization, process exit behavior, hook trust, and the agent’s enforcement logic must all work together.
Is fail-open the right design?
dcg intentionally prioritizes workflow continuity. Unknown commands are allowed. Parser failures and timeouts generally allow execution, with lightweight fallback checks for especially dangerous patterns. The heredoc pipeline has bounded resource limits, and hook evaluation has an absolute time budget rather than hanging the agent indefinitely.
That choice has a real trade-off:
- Fail open reduces the chance that a broken hook stops all developer work.
- Fail closed reduces the chance that a broken hook silently permits a dangerous operation.
The default is reasonable for a developer productivity tool that observes arbitrary shell input, but it is not a high-assurance boundary. dcg provides opt-in fail-closed settings for stricter environments, including DCG_FAIL_CLOSED=1 for unparseable top-level hook input. Turning that on can increase protection and increase operational friction at the same time.
Teams should decide based on the cost of failure. A local throwaway repository may prefer continuity. An agent holding production credentials should probably have stronger controls than one pattern hook, regardless of dcg mode.
What Destructive Command Guard does not protect
This is where many “AI safety tool” articles become misleading. dcg is valuable precisely because its scope is narrow. It is not a complete agent security system.
Direct non-shell mutations
If an agent can delete or overwrite files through a native file-editing tool, Python library call, API connector, or IDE operation that never reaches the monitored shell hook, dcg may not see it.
Destructive behavior hidden behind a script
The interactive hook evaluates the command the agent proposes. If the command is ./deploy.sh, the hook does not automatically prove every operation inside that script is safe. dcg’s separate scan command can inspect supported executable contexts in shell scripts, Dockerfiles, CI workflows, Makefiles, package scripts, Terraform, PowerShell, and other formats, but that is a different workflow.
Unknown patterns and logic errors
Default allow means a destructive operation not covered by an enabled rule can pass. A command can also be syntactically safe and still be logically wrong: deploying to the wrong environment, overwriting a valid object with bad data, or executing a correctly spelled migration against the wrong database.
Missing, stale, or untrusted hooks
An installed binary offers no protection if the agent never invokes it. Configuration can be overwritten, user hooks can require trust, PATH resolution can differ between interactive and hook shells, and old binaries can implement stale protocols.
Malicious agents or users
dcg assumes a well-intentioned but fallible agent. A determined actor with the same user permissions can bypass, disable, or route around it. The documented DCG_BYPASS=1 escape hatch intentionally disables protection for a single invocation.
This is why secure agent skills and MCP security need capability scoping, secret isolation, provenance checks, and review in addition to command filtering.
dcg vs permissions, sandboxes, approvals, and backups
These controls solve different problems and should be layered.
| Control | Primary job | What it catches | What it misses |
|---|---|---|---|
| Agent permissions | Decide which tools or command families are callable | Broad denied capabilities | Dangerous commands inside an allowed family; configuration mistakes |
| dcg policy hook | Inspect proposed shell command text | Known destructive patterns with contextual rules | Unknown patterns, non-shell actions, hook failures |
| OS or container sandbox | Restrict filesystem, network, and process reach | Writes outside allowed roots; inaccessible credentials | Damage inside the allowed workspace or mounted resources |
| Human approval | Apply judgment before risky operations | Context-specific intent and unexpected scope | Fatigue, rubber-stamping, high-volume autonomous work |
| Git checkpoints and backups | Make damage recoverable | Accidental deletion or corruption after the fact | Secrets exposure, external side effects, uncommitted work not captured |
| Least-privilege credentials | Limit blast radius | Access outside the agent’s assigned role | Destructive actions still permitted within that role |
Our four-layer agent engineering model puts dcg in the harness layer. It is runtime enforcement around the model, not another instruction inside the prompt. That is stronger than asking an agent to “be careful,” because the guard gets an independent decision point.
It still benefits from human-in-the-loop gates for payments, production infrastructure, migrations, identity, secrets, and other high-impact actions. The goal is not to choose one perfect control. It is to make one failure insufficient to cause catastrophe.
How teams should roll out dcg
Start with observation and deliberately expand coverage.
1. Inventory the agent’s actual capabilities
List the shells, databases, cloud CLIs, deployment tools, package registries, payment systems, and credentials available to the agent. Enabling a Kubernetes pack is irrelevant if the environment has no cluster access; omitting it is dangerous if kubectl points at production.
2. Test core decisions before enabling broad packs
Use dcg test so commands are evaluated without execution:
dcg test "git reset --hard HEAD~1"
dcg test "git status"
dcg test --with-packs containers.docker "docker system prune"
dcg explain "git restore src/config.ts"
The first pair checks a block and allow. --with-packs previews an opt-in pack without changing the permanent config. dcg explain shows normalization, matching rule, reasoning, and suggested alternatives.
3. Enable relevant packs, not every pack
Roll out database, cloud, infrastructure, and platform rules based on observed command traffic. Review false positives and use narrow allowlists with reasons and expiration dates rather than disabling whole categories.
4. Verify each agent protocol separately
Claude Code, Codex, Gemini, Copilot, Cursor, and other hosts do not share one universal hook response format. Confirm that an actual denied command is reported as blocked in every agent your team uses.
5. Add repository scanning to CI
The runtime hook cannot see every command hidden in committed automation. dcg can scan staged changes or Git diffs and extract executable contexts:
dcg scan --staged --fail-on error
Begin with catastrophic rules in workflows, Dockerfiles, Makefiles, and shell scripts. Warn-first rollout is usually better than introducing a broad blocking gate that developers immediately bypass.
6. Preserve recovery systems
Commit frequently, push important branches, back up databases, version infrastructure, use protected environments, and keep destructive production access out of everyday agent sessions. Our article on reviewing AI-generated code makes the same point at the implementation layer: automation can reduce review volume, but it cannot remove accountability.
Is dcg worth using?
Yes, for developers who let coding agents run shell commands, dcg is a sensible defense-in-depth layer. It covers a class of high-cost mistakes with low routine overhead, gives denials useful explanations, and centralizes policy across multiple agent tools.
Its strongest ideas are not the long pack list. They are the operational details: commands are evaluated before execution, safe and destructive contexts are distinguished, exceptions can be scoped, CI can reuse the policy engine, and agent-specific response protocols are tested rather than assumed identical.
But dcg should make you less complacent, not more. A fail-open command matcher cannot guarantee safety. The v0.6.5 Codex incident demonstrates that even correct detection is useless if the host treats a denial as a hook error. Direct tools, scripts, unknown commands, stale configuration, and overly powerful credentials remain real paths around the guard.
Install it if the supported agents and command packs match your workflow. Then test it, watch its version, enable only the packs you need, and keep the rest of the safety stack intact.
Related on explainx.ai
- Codex $HOME deletion — full access + GPT-5.6 (Tibo Jul 16)
- Claude Code Hooks: Automate Actions Before and After Every Tool Call
- Claude Code settings.json: Every Option Explained
- Context vs Prompt vs Loop vs Harness Engineering
- Should Developers Stop Reviewing AI-Generated Code?
- MCP Security Guide for 2026
- Agent Skills Security Guide
- Antigravity CLI: Sandboxes, Plugins, and Subagents
- Top AI Tools for Coding in 2026
Official resources
- Destructive Command Guard repository
- dcg changelog
- Codex integration reference
- Pack index
- Security documentation
- Open issues
Repository features, issue status, release availability, star counts, and agent compatibility were checked on July 13, 2026. dcg changes quickly; verify the installed version, current release notes, and your agent’s hook contract before treating any denial path as operational.