Destructive Command Guard
ReviewAudited by ClawScan on May 10, 2026.
Overview
This appears to be a legitimate command-safety tool, but users should review it because the artifacts show possible protection gaps, an unpinned remote installer, and local command-history/telemetry storage.
Before installing, verify the exact source and release, avoid unreviewed curl-to-bash installation if possible, test the hook against the specific packs you plan to rely on, and review or disable any history/telemetry storage. Treat it as a helpful guardrail, not a complete guarantee against destructive commands.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A user may believe destructive non-core commands are blocked when the actual hook path may allow them.
The artifact itself describes a current protection gap that can contradict the README/SKILL claims about broad Docker, Kubernetes, database, cloud, and other pack coverage.
Non-Core Packs Are Unreachable in Hook Mode ... enabled packs can silently not run ... `dcg test` might report "BLOCKED," while the actual hook would allow the same command.
Before relying on this as a safety layer, test hook-mode behavior for every enabled pack and treat broad pack claims as unverified until the maintainer demonstrates the gap is fixed.
Installing this way can run code that differs from the reviewed package version.
The recommended quick install executes a mutable remote script from the master branch with cache busting, rather than a pinned reviewed artifact.
curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/master/install.sh?$(date +%s)" | bash -s -- --easy-mode
Prefer a pinned release with checksum verification or review the installer locally before running it; the maintainer should publish a pinned install spec for the registry version.
Shell commands can contain secrets, tokens, private paths, or project-sensitive details that may remain in local history or exports.
The tool sees shell commands, and these dependency comments indicate persistent telemetry/history storage and export. The provided artifacts do not clearly bound what command data is stored, redacted, retained, or exported.
rusqlite = { version = "0.35", features = ["bundled"] } # Telemetry database ... flate2 = "1.0" # Gzip compression for history exportReview and configure history/telemetry settings before use, clear stored history if not needed, and avoid putting secrets directly in shell commands.
The tool can affect future agent command execution by allowing or denying commands.
A persistent command hook is central to the stated purpose and is disclosed, but it will continue mediating agent shell commands once installed.
Claude Code calls `dcg` as a `PreToolUse` hook: ... Extract Bash command string ... Quick reject / keyword gating
Understand where the hook is installed, keep an uninstall path available, and verify that its allow/deny policy matches your workflow.
Connected agents may be able to ask the tool to inspect commands or files, depending on how the MCP server is enabled.
MCP/server integration and file scanning are purpose-aligned, but they create an agent-facing interface that can process command text and selected file contents.
dcg includes an MCP server mode (`dcg mcp-server`) exposing: - `check_command`: Evaluate a command - `scan_file`: Scan files for destructive commands - `explain_pattern`: Explain a dcg rule
Enable MCP mode only for trusted agents and projects, and confirm what file paths the connected agent is allowed to scan.