Destructive Command Guard (dcg)

What it is

Destructive Command Guard (dcg) is a high‑performance hook that sits between AI‑driven coding assistants (Claude, Codex, Gemini, GitHub Copilot, Cursor, etc.) and the shell. When an assistant tries to run a command that could delete or corrupt code, data, or infrastructure, dcg intercepts the request, evaluates it against a large library of safety rules (called packs), and either blocks it with a clear explanation or lets it pass.

Why it matters

AI coding agents are increasingly used to write and run code automatically. A single mistaken command such as git reset --hard, rm -rf /, or aws ec2 terminate-instances can wipe hours of work or shut down production services. dcg provides zero‑configuration protection for these agents, catching destructive commands before they hit the filesystem, version‑control system, or cloud provider.

Core features (as described in the README)

Feature	What you get
Broad agent support	Hooks for Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, VS Code Copilot Chat, Cursor, Hermes Agent, Posit Assistant, Grok (xAI), Oh My Pi, and more.
Modular “packs”	50+ pre‑written rule packs covering filesystems, Git, databases, Docker, Kubernetes, AWS/GCP/Azure, Terraform, etc. Packs can be enabled/disabled per‑agent or globally.
Sub‑millisecond latency	SIMD‑accelerated regex filtering makes the guard invisible to the user.
Heredoc / inline‑script scanning	Detects dangerous commands hidden inside python -c, shell scripts, or heredocs.
Smart context detection	Differentiates data that looks like a command (e.g., grep "rm -rf") from an actual executable command.
Rich terminal UI	Human‑readable denial panels on stderr with the reason and a safer alternative.
Machine‑readable output	JSON denial payload on stdout for agents that expect a hook protocol (e.g., Codex).
Explain mode	dcg explain "<command>" shows why a command would be blocked.
CI / pre‑commit scanning	dcg can run in scan mode to catch dangerous commands during code review.
Bypass & allow‑list	Temporary bypass via DCG_BYPASS=1, one‑time allow codes, or permanent allow‑list entries.
Agent‑specific profiles	Different trust levels and rule sets per agent (e.g., more permissive for Claude, stricter for unknown agents).
Cross‑platform installers	One‑line curl installer for Linux/macOS, PowerShell installer for native Windows, with optional signature verification.

How it works (high‑level)

1. Installation – The installer drops a binary (dcg or dcg.exe) and registers a hook file in the configuration directory of the target AI agent (e.g., ~/.claude/settings.json).
2. Invocation – When the agent wants to run a command, it calls the hook. The hook receives the command string and some metadata.
3. Evaluation – dcg matches the command against enabled packs using compiled regexes. Packs are grouped by category (e.g., core.filesystem, database.postgresql).
4. Decision – Based on the rule’s severity (critical, high, medium, etc.) the outcome is:
   • deny – block the command, print a colored panel with a tip, and return a JSON denial for the agent.
   • ask – request human review if the agent protocol supports it.
   • warn / log – let the command run but record the event.
5. Output – Human‑friendly message on stderr; machine‑friendly JSON on stdout.
6. Configuration – Users edit ~/.config/dcg/config.toml to enable extra packs, adjust policies, or set per‑agent profiles.

Who might use it

• Developers who rely on Claude, Copilot, Gemini, or other LLM‑powered coding assistants and want a safety net against accidental destructive commands.
• Teams integrating AI agents into CI pipelines; dcg can be run as a pre‑commit hook to prevent dangerous commands from being committed.
• Ops / DevOps engineers who use AI agents to manage cloud resources, containers, or Kubernetes and need protection against accidental terraform destroy, kubectl delete, or aws ec2 terminate‑instances.

Getting started (quick steps from the README)

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

The installer detects your platform, verifies signatures when possible, adds dcg to your PATH, runs a self‑test, and configures hooks for all supported agents.

After installation, the default configuration already protects the most catastrophic commands (core.filesystem, core.git, system.disk, and Windows‑specific packs). To add more protection, edit ~/.config/dcg/config.toml:

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

Limitations & considerations (as per README)

• Core packs (core.filesystem, core.git) are always evaluated; they cannot be disabled, though their policy can be relaxed per‑rule.
• The hook only works for agents that support the Claude‑style hook protocol; for others it may fall back to detection‑only mode.
• Bypass mechanisms exist; misuse could re‑introduce risk, so they should be used sparingly.
• Adding many packs may increase memory usage, but the SIMD engine keeps latency sub‑millisecond.

---

In short: dcg is a Rust‑based safety layer that intercepts commands issued by AI coding assistants, matches them against a comprehensive rule set, and blocks anything that could cause irreversible damage, all while staying fast enough to be invisible to the user.