destructive_command_guard

Mon, 13 Jul 2026 18:37:26 +0800

Dicklesworthstone/destructive_command_guard

dcg (Destructive Command Guard)

A high-performance hook for AI coding agents that blocks destructive commands before they execute, protecting your work from accidental deletion across Claude Code, Codex CLI, Gemini CLI, Copilot CLI, VS Code Copilot Chat, Cursor, Hermes Agent, Grok (xAI), and related tools.

Supported: Claude Code, Codex CLI 0.125.0+, Gemini CLI, GitHub Copilot CLI, VS Code Copilot Chat, Cursor IDE, Hermes Agent, Grok (xAI) (native ~/.grok/hooks/ plus Claude compatibility layer), Antigravity CLI (agy) (native ~/.gemini/config/hooks.json via dcg install --agy), OpenCode (via community plugin), Pi (via extension recipe), Aider (limited—git hooks only), Continue (detection only)

Quick Install

`1`	`curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" \| bash -s -- --easy-mode`

Works on Linux, macOS, and Windows via WSL. Auto-detects your platform, downloads the right binary, and configures supported agent hooks including Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, VS Code Copilot Chat (through VS Code's Claude-hook compatibility), Cursor IDE, Hermes Agent, and Grok (xAI) (via dcg install --grok for a native ~/.grok/hooks/dcg.json, or via the Claude compatibility layer automatically picked up by Grok). For native Windows, use the PowerShell installer below.

Windows (native, PowerShell)

`1`	`& ([scriptblock]::Create((irm "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.ps1"))) -EasyMode -Verify`

Installs native dcg.exe, verifies the SHA256 checksum (and the Sigstore/cosign signature when cosign is present), adds it to your User PATH (-EasyMode), runs a self-test (-Verify), and configures detected agent hooks for Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, Cursor IDE, and Hermes Agent. Copilot is configured at the user level under %COPILOT_HOME%\hooks (or %USERPROFILE%\.copilot\hooks) so every workspace is protected. On Windows the windows.filesystem and windows.system packs are on by default, so del /s, rd /s, Remove-Item -Recurse -Force, format, and vssadmin delete shadows are blocked out of the box. Pin a version with -Version vX.Y.Z.

TL;DR

The Problem: AI coding agents (Claude, Codex, Gemini, Copilot, etc.) occasionally run catastrophic commands like git reset --hard, rm -rf ./src, or DROP TABLE users—destroying hours of uncommitted work in seconds.

The Solution: dcg is a high-performance hook that intercepts destructive commands before they execute, blocking them with clear explanations and safer alternatives.

Why Use dcg?

Feature	What It Does
Zero-Config Protection	Blocks dangerous git/filesystem commands out of the box
50+ Security Packs	Databases, Kubernetes, Docker, AWS/GCP/Azure, Terraform, and more
Sub-Millisecond Latency	SIMD-accelerated filtering—you won’t notice it’s there
Heredoc/Inline Script Scanning	Catches `python -c "os.remove(...)"` and embedded shell scripts
Smart Context Detection	Won’t block `grep "rm -rf"` (data) but will block `rm -rf /` (execution)
Rich Terminal Output	Human-readable denial panels, rule context, and suggestions on stderr
Agent-Safe Streams	Machine-readable hook output stays on stdout while rich UI stays on stderr
Native Codex Support	Codex CLI 0.125.0+ receives a minimal stdout JSON denial that current clients enforce reliably
Graceful Degradation	Plain output for CI, pipes, dumb terminals, and no-color environments
Scan Mode for CI	Pre-commit hooks and CI integration to catch dangerous commands in code review
Fail-Open Design	Never blocks your workflow due to timeouts or parse errors
Explain Mode	`dcg explain "command"` shows exactly why something is blocked

Quick Example

# AI agent tries to run:
$ git reset --hard HEAD~5

# dcg intercepts and blocks:
════════════════════════════════════════════════════════════════
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.
════════════════════════════════════════════════════════════════

Enable More Protection

# ~/.config/dcg/config.toml
[packs]
enabled = [
    "database.postgresql",    # Blocks DROP TABLE, TRUNCATE
    "kubernetes.kubectl",     # Blocks kubectl delete namespace
    "cloud.aws",              # Blocks aws ec2 terminate-instances
    "containers.docker",      # Blocks docker system prune
]

Agent-Specific Profiles

dcg automatically detects which AI coding agent is invoking it and can apply agent-specific configuration. The trust_level field is an advisory label recorded in JSON output and logs — it does not directly change rule evaluation. Behavioral differences come from the other profile fields:

Option	Effect
`disabled_packs`	Removes rule packs from evaluation
`extra_packs`	Adds rule packs to evaluation
`additional_allowlist`	Adds command patterns that bypass deny rules
`disabled_allowlist`	When `true`, ignores all allowlist entries

# Trust Claude Code more — wider allowlist, fewer packs
[agents.claude-code]
trust_level = "high"
additional_allowlist = ["npm run build", "cargo test"]
disabled_packs = ["kubernetes"]

# Restrict unknown agents — extra rules, no allowlist bypass
[agents.unknown]
trust_level = "low"
extra_packs = ["paranoid"]
disabled_allowlist = true

See docs/agents.md for full documentation on supported agents, trust levels, and configuration options.

Codex Support

dcg now treats Codex CLI as a first-class hook target, not just a Claude-shaped compatibility path. The installer configures Codex CLI 0.125.0+ automatically when it detects codex on PATH or an existing ~/.codex/ directory.

Codex behavior	dcg handling
Hook config	Merges a `PreToolUse` Bash hook into `~/.codex/hooks.json`
Denied command	Exits 0 with a minimal `hookSpecificOutput` denial on stdout; human warning stays on stderr
Allowed command	Exits 0 with empty stdout and stderr
Existing hooks	Preserves coexisting hooks, keeps dcg first for Bash, and refuses to overwrite malformed JSON
Validation	Covered by subprocess protocol tests plus an opt-in real Codex E2E harness

Codex’s hook input is intentionally close to Claude Code’s, but Codex rejects unknown fields in hook output. dcg detects Codex payloads from the non-empty turn_id field and emits only Codex’s documented denial fields so a blocked command is reported as blocked rather than as a failed hook. See docs/codex-integration.md for protocol details, manual probes, and troubleshooting.

Origins & Authors

This project began as a Python script by Jeffrey Emanuel, who recognized that AI coding agents, while incredibly useful, occasionally run catastrophic commands that destroy hours of uncommitted work. The original implementation was a simple but effective hook that intercepted dangerous git and filesystem commands before execution.

Jeffrey Emanuel - Original concept and Python implementation (source); substantially expanded the Rust version with the modular pack system (50+ security packs), heredoc/inline-script scanning, the three-tier architecture, context classification, allowlists, scan mode, and the dual regex engine
Darin Gordon - Initial Rust port with performance optimizations

The initial Rust port by Darin maintained pattern compatibility with the original Python implementation while adding sub-millisecond execution through SIMD-accelerated filtering and lazy-compiled regex patterns. Jeffrey subsequently expanded the Rust codebase dramatically to add the features described above.

Escape Hatch / Bypass

If dcg is blocking something you genuinely need to run:

Method	Scope	How
Env var bypass	Single command	`DCG_BYPASS=1 <command>`
Allow-once code	Single command	Copy the short code from the block message, run `dcg allow-once <code>`
Permanent allowlist	Rule or command	`dcg allowlist add core.git:reset-hard -r "reason"`
Remove the hook	All commands	Delete or comment out the dcg entry in `~/.claude/settings.json` (or equivalent for your agent)

DCG_BYPASS=1 disables all protection for that invocation. Use it sparingly and prefer allowlists for recurring needs.

Modular Pack System

dcg uses a modular “pack” system to organize destructive command patterns by category. Packs can be enabled or disabled in the configuration file.

Full pack ID index: docs/packs/README.md
Canonical descriptions + pattern counts: dcg packs --verbose

Enabled by default (no config file)

With no config file present, dcg enables only the packs that guard against the most catastrophic, unrecoverable mistakes:

core.filesystem - Dangerous rm -rf outside temp directories (always on; cannot be disabled)
core.git - Destructive git commands that lose uncommitted work, rewrite history, or destroy stashes (always on; cannot be disabled)
system.disk - mkfs, dd-to-device, fdisk, parted, mdadm, lvm removal, wipefs (on by default; opt out with disabled = ["system.disk"])

On Windows, two additional packs are on by default so a fresh install blocks the catastrophic native-Windows operations with no config:

windows.filesystem - cmd del /s, rd /s, format <drive>: and PowerShell Remove-Item -Recurse -Force (and aliases), Clear-Content, Clear-RecycleBin (default-on on Windows only; opt out with disabled = ["windows.filesystem"] or ["windows"])
windows.system - vssadmin delete shadows / wmic shadowcopy delete (Volume Shadow Copy destruction), diskpart, Format-Volume, Clear-Disk, Remove-Partition, cipher /w, bcdedit /delete (default-on on Windows only; opt out with disabled = ["windows.system"] or ["windows"])

The broader windows.misc (reg delete, net user /delete, wsl --unregister, robocopy /MIR) and windows.powershell (registry/provider deletes, Remove-LocalUser, Disable-ComputerRestore, Remove-VM) packs are opt-in on every platform. On Unix the windows.* packs are registered but off by default; enable them (e.g. to scan committed .ps1/.cmd scripts in CI) via [packs] enabled = ["windows"].

Every other pack — including database.postgresql and containers.docker — is opt-in and is not active until a config file enables it. Running dcg init writes a starter ~/.config/dcg/config.toml whose [packs] enabled list turns on database.postgresql and containers.docker as common examples, but that is a generated starter config, not the no-config default. Enable any pack below by adding it to [packs] enabled — see Enable More Protection.

Storage Packs

storage.s3 - Protects against destructive S3 operations like bucket removal, recursive deletes, and sync –delete.
storage.gcs - Protects against destructive GCS operations like bucket removal, object deletion, and recursive deletes.
storage.minio - Protects against destructive MinIO Client (mc) operations like bucket removal, object deletion, and admin operations.
storage.azure_blob - Protects against destructive Azure Blob Storage operations like container deletion, blob deletion, and azcopy remove.

Remote Packs

remote.rsync - Protects against destructive rsync operations like –delete and its variants.
remote.scp - Protects against destructive SCP operations like overwrites to system paths.
remote.ssh - Protects against destructive SSH operations like remote command execution and key management.

Database Packs

database.postgresql - Protects against destructive PostgreSQL operations like DROP DATABASE, TRUNCATE, and dropdb.
database.mysql - MySQL/MariaDB guard.
database.mongodb - Protects against destructive MongoDB operations like dropDatabase, dropCollection, and remove without criteria.
database.redis - Protects against destructive Redis operations like FLUSHALL, FLUSHDB, and mass key deletion.
database.sqlite - Protects against destructive SQLite operations like DROP TABLE, DELETE without WHERE, and accidental data loss.
database.supabase - Protects against destructive Supabase CLI operations including database resets, migration rollbacks, function/secret/storage deletion, project removal, and infrastructure changes.

Container Packs

containers.docker - Protects against destructive Docker operations like system prune, volume prune, and force removal.
containers.compose - Protects against destructive Docker Compose operations like down -v which removes volumes.
containers.podman - Protects against destructive Podman operations like system prune, volume prune, and force removal.

Kubernetes Packs

kubernetes.kubectl - Protects against destructive kubectl operations like delete namespace, drain, and mass deletion.
kubernetes.helm - Protects against destructive Helm operations like uninstall and rollback without dry-run.
kubernetes.kustomize - Protects against destructive Kustomize operations when combined with kubectl delete or applied without review.

Cloud Provider Packs

cloud.aws - Protects against destructive AWS CLI operations like terminate-instances, delete-db-instance, and s3 rm –recursive.
cloud.azure - Protects against destructive Azure CLI operations like vm delete, storage account delete, and resource group delete.
cloud.gcp - Protects against destructive gcloud operations like instances delete, sql instances delete, and gsutil rm -r.

CDN Packs

cdn.cloudflare_workers - Protects against destructive Cloudflare Workers, KV, R2, and D1 operations via the Wrangler CLI.
cdn.cloudfront - Protects against destructive AWS CloudFront operations like deleting distributions, cache policies, and functions.
cdn.fastly - Protects against destructive Fastly CLI operations like service, domain, backend, and VCL deletion.

API Gateway Packs

apigateway.apigee - Protects against destructive Google Apigee CLI and apigeecli operations.
apigateway.aws - Protects against destructive AWS API Gateway CLI operations for both REST APIs and HTTP APIs.
apigateway.kong - Protects against destructive Kong Gateway CLI, deck CLI, and Admin API operations.

Infrastructure Packs

infrastructure.ansible - Protects against destructive Ansible operations like dangerous shell commands and unchecked playbook runs.
infrastructure.atmos - Protects against destructive Atmos operations like terraform deploy (auto-approve), clean, destroy, state rm/taint, and helmfile destroy.
infrastructure.pulumi - Protects against destructive Pulumi operations like destroy and up with -y (auto-approve).
infrastructure.terraform - Protects against destructive Terraform operations like destroy, taint, and apply with -auto-approve.

System Packs

system.disk - Protects against destructive disk operations including dd to devices, mkfs, partition table modifications (fdisk/parted), RAID management (mdadm), btrfs filesystem operations, device-mapper (dmsetup), network block devices (nbd-client), and LVM commands (pvremove, vgremove, lvremove, lvreduce, pvmove).
system.permissions - Protects against dangerous permission changes like chmod 777, recursive chmod/chown on system directories.
system.services - Protects against dangerous service operations like stopping critical services and modifying init configuration.

CI/CD Packs

cicd.circleci - Protects against destructive CircleCI operations like deleting contexts, removing secrets, deleting orbs/namespaces, or removing pipelines.
cicd.github_actions - Protects against destructive GitHub Actions operations like deleting secrets/variables or using gh api DELETE against /actions endpoints.
cicd.gitlab_ci - Protects against destructive GitLab CI/CD operations like deleting variables, removing artifacts, and unregistering runners.
cicd.jenkins - Protects against destructive Jenkins CLI/API operations like deleting jobs, nodes, credentials, or build history.

Secrets Management Packs

secrets.aws_secrets - Protects against destructive AWS Secrets Manager and SSM Parameter Store operations like delete-secret and delete-parameter.
secrets.doppler - Protects against destructive Doppler CLI operations like deleting secrets, configs, environments, or projects.
secrets.onepassword - Protects against destructive 1Password CLI operations like deleting items, documents, users, groups, and vaults.
secrets.vault - Protects against destructive Vault CLI operations like deleting secrets, disabling auth/secret engines, revoking leases/tokens, and deleting policies.

Platform Packs

platform.github - Protects against destructive GitHub CLI operations like deleting repositories, gists, releases, or SSH keys.
platform.gitlab - Protects against destructive GitLab platform operations like deleting projects, releases, protected branches, and webhooks.
platform.kamal - Protects against destructive Kamal 2.x operations that tear down the stack (kamal remove), delete accessory data directories (kamal accessory remove), drop proxy routing, take the app offline, or prune the images that kamal rollback relies on.
platform.modal - Protects against destructive Modal serverless platform operations like recursive volume removal, app stops with --force, and secret deletion.
platform.railway - Protects against destructive Railway CLI and Public API operations that can delete projects, environments, services, functions, volumes, variables, or deployments.

DNS Packs

dns.cloudflare - Protects against destructive Cloudflare DNS operations like record deletion, zone deletion, and targeted Terraform destroy.
dns.generic - Protects against destructive or risky DNS tooling usage (nsupdate deletes, zone transfers).
dns.route53 - Protects against destructive AWS Route53 DNS operations like hosted zone deletion and record set DELETE changes.

Email Packs

email.mailgun - Protects against destructive Mailgun API operations like domain deletion, route deletion, and mailing list removal.
email.postmark - Protects against destructive Postmark API operations like server deletion, template deletion, and sender signature removal.
email.sendgrid - Protects against destructive SendGrid API operations like template deletion, API key deletion, and domain authentication removal.
email.ses - Protects against destructive AWS Simple Email Service operations like identity deletion, template deletion, and configuration set removal.

Feature Flag Packs

featureflags.flipt - Protects against destructive Flipt CLI and API operations.
featureflags.launchdarkly - Protects against destructive LaunchDarkly CLI and API operations.
featureflags.split - Protects against destructive Split.io CLI and API operations.
featureflags.unleash - Protects against destructive Unleash CLI and API operations.

Load Balancer Packs

loadbalancer.elb - Protects against destructive AWS Elastic Load Balancing (ELB/ALB/NLB) operations like deleting load balancers, target groups, or deregistering targets from live traffic.
loadbalancer.haproxy - Protects against destructive HAProxy load balancer operations like stopping the service or disabling backends via runtime API.
loadbalancer.nginx - Protects against destructive nginx load balancer operations like stopping the service or deleting config files.
loadbalancer.traefik - Protects against destructive Traefik load balancer operations like stopping containers, deleting config, or API deletions.

Messaging Packs

messaging.kafka - Protects against destructive Kafka CLI operations like deleting topics, removing consumer groups, resetting offsets, and deleting records.
messaging.nats - Protects against destructive NATS/JetStream operations like deleting streams, consumers, key-value entries, objects, and accounts.
messaging.rabbitmq - Protects against destructive RabbitMQ operations like deleting queues/exchanges, purging queues, deleting vhosts, and resetting cluster state.
messaging.sqs_sns - Protects against destructive AWS SQS and SNS operations like deleting queues, purging messages, deleting topics, and removing subscriptions.

Monitoring Packs

monitoring.datadog - Protects against destructive Datadog CLI/API operations like deleting monitors and dashboards.
monitoring.newrelic - Protects against destructive New Relic CLI/API operations like deleting entities or alerting resources.
monitoring.pagerduty - Protects against destructive PagerDuty CLI/API operations like deleting services and schedules (which can break incident routing).
monitoring.prometheus - Protects against destructive Prometheus/Grafana operations like deleting time series data or dashboards/datasources.
monitoring.splunk - Protects against destructive Splunk CLI/API operations like index removal and REST API DELETE calls.

Payment Packs

payment.braintree - Protects against destructive Braintree/PayPal payment operations like deleting customers or cancelling subscriptions via API/SDK calls.
payment.square - Protects against destructive Square CLI/API operations like deleting catalog objects or customers (which can break payment flows).
payment.stripe - Protects against destructive Stripe CLI/API operations like deleting webhook endpoints and customers, or rotating API keys without coordination.

Search Engine Packs

search.algolia - Protects against destructive Algolia operations like deleting indices, clearing objects, removing rules/synonyms, and deleting API keys.
search.elasticsearch - Protects against destructive Elasticsearch REST API operations like index deletion, delete-by-query, index close, and cluster setting changes.
search.meilisearch - Protects against destructive Meilisearch REST API operations like index deletion, document deletion, delete-batch, and API key removal.
search.opensearch - Protects against destructive OpenSearch REST API operations and AWS CLI domain deletions.

Backup Packs

backup.borg - Protects against destructive borg operations like delete, prune, compact, and recreate.
backup.rclone - Protects against destructive rclone operations like sync, delete, purge, dedupe, and move.
backup.restic - Protects against destructive restic operations like forgetting snapshots, pruning data, removing keys, and cache cleanup.
backup.velero - Protects against destructive velero operations like deleting backups, schedules, and locations.

Windows Packs

Native-Windows (cmd.exe + PowerShell) destructive-command protection. windows.filesystem and windows.system are default-on on Windows (off/opt-in on Unix); windows.misc and windows.powershell are opt-in everywhere. All patterns are case-insensitive.

windows.filesystem - Recursive/forced filesystem destruction: cmd del /s, rd /s/rmdir /s, format <drive>:; PowerShell Remove-Item -Recurse -Force (and aliases rm/del/rd/ri), Clear-Content, Clear-RecycleBin. Whitelists PowerShell -WhatIf previews only on cmdlets/aliases that honor it, plus temp-dir deletes.
windows.system - Catastrophic disk/system operations: vssadmin delete shadows and wmic shadowcopy delete (Volume Shadow Copy destruction — a ransomware hallmark), diskpart, Format-Volume, Clear-Disk, Remove-Partition, Initialize-Disk/Reset-PhysicalDisk, cipher /w, bcdedit /delete.
windows.misc - Registry/account/service/WSL/copy destruction: reg delete, net user|localgroup /delete, sc delete, schtasks /delete, wsl --unregister (destroys a WSL distro), robocopy /MIR (mirror-delete).
windows.powershell - Destructive PowerShell cmdlets: registry/provider deletes (Remove-Item HKLM:\, Remove-ItemProperty, Remove-PSDrive), Remove-LocalUser/Remove-LocalGroup, Unregister-ScheduledTask, Disable-ComputerRestore, forced Stop-Computer/Restart-Computer, Remove-VM/Remove-AppxPackage.

Other Packs

package_managers - Protects against dangerous package manager operations like publishing packages and removing critical system packages.
strict_git - Stricter git protections: blocks all force pushes, rebases, and history rewriting operations.

Enable packs in ~/.config/dcg/config.toml:

[packs]
enabled = [
    # Databases
    "database.postgresql",
    "database.redis",
    "database.supabase",

    # Containers and orchestration
    "containers.docker",
    "kubernetes",  # Enables all kubernetes sub-packs

    # Cloud providers
    "cloud.aws",
    "cloud.gcp",

    # Secrets management
    "secrets.aws_secrets",
    "secrets.vault",

    # CI/CD
    "cicd.jenkins",
    "cicd.gitlab_ci",

    # Messaging
    "messaging.kafka",
    "messaging.sqs_sns",

    # Search engines
    "search.elasticsearch",

    # Backup
    "backup.restic",

    # Platform
    "platform.github",
    "platform.railway",

    # Monitoring
    "monitoring.splunk",
]

Custom Packs

Create your own organization-specific security packs using YAML files. Custom packs let you define patterns for internal tools, deployment scripts, and proprietary systems without modifying dcg.

[packs]
custom_paths = [
    "~/.config/dcg/packs/*.yaml",      # User packs
    ".dcg/packs/*.yaml",               # Project-local packs
]

For detailed pack authoring guide, schema reference, and examples, see docs/custom-packs.md.

Validate your pack before deployment:

`1`	`dcg pack validate mypack.yaml`

Heredoc scanning configuration:

[heredoc]
# Enable scanning for heredocs and inline scripts (python -c, bash -c, etc.).
enabled = true

# Extraction timeout budget (milliseconds).
timeout_ms = 50

# Resource limits for extracted bodies.
max_body_bytes = 1048576
max_body_lines = 10000
max_heredocs = 10

# Optional language filter (scan only these languages). Omit for "all".
# languages = ["python", "bash", "javascript", "typescript", "ruby", "perl", "go"]

# Graceful degradation (hook defaults are fail-open).
fallback_on_parse_error = true
fallback_on_timeout = true

CLI overrides for heredoc scanning:

--heredoc-scan / --no-heredoc-scan
--heredoc-timeout <ms>
--heredoc-languages <lang1,lang2,...>

Heredoc documentation:

docs/adr-001-heredoc-scanning.md (architecture and rationale)
docs/patterns.md (pattern authoring + inventory)
docs/security.md (threat model and incident response)

Heredoc Three-Tier Architecture

Heredoc and inline script scanning uses a three-tier pipeline designed for performance and accuracy:

Command Input
     │
     ▼
┌─────────────────┐
│ Tier 1: Trigger │ ─── No match ──► ALLOW (fast path, <100μs)
│   (RegexSet)    │
└────────┬────────┘
         │ Match
         ▼
┌─────────────────┐
│ Tier 2: Extract │ ─── Error/Timeout ──► ALLOW + fallback check
│   (<1ms)        │
└────────┬────────┘
         │ Success
         ▼
┌─────────────────┐
│ Tier 3: AST     │ ─── No match ──► ALLOW
│   (<5ms)        │ ─── Match ──► BLOCK
└─────────────────┘

Tier 1: Trigger Detection (<100μs)

Ultra-fast regex screening to detect heredoc indicators. Uses a compiled RegexSet for O(n) matching against all trigger patterns simultaneously:

static HEREDOC_TRIGGERS: LazyLock<RegexSet> = LazyLock::new(|| {
    RegexSet::new([
        r"<<-?\s*(?:['\x22][^'\x22]*['\x22]|[\w.-]+)",  // Heredocs
        r"<<<",                                          // Here-strings
        r"\bpython[0-9.]*\b.*\s+-[A-Za-z]*[ce]",        // python -c/-e
        r"\bruby[0-9.]*\b.*\s+-[A-Za-z]*e",             // ruby -e
        r"\bnode(js)?[0-9.]*\b.*\s+-[A-Za-z]*[ep]",     // node -e/-p
        r"\b(sh|bash|zsh)\b.*\s+-[A-Za-z]*c",           // bash -c
        // ... more patterns
    ])
});

Commands without any trigger patterns skip directly to ALLOW—no further processing needed.

Tier 2: Content Extraction (<1ms)

For commands that trigger, extract the actual content to be evaluated:

Heredocs: cat <<EOF ... EOF → extracts body between delimiters
Here-strings: cat <<< "content" → extracts quoted content
Inline scripts: python -c "code" → extracts the code argument

Extraction is bounded by configurable limits:

Maximum body size (default: 1MB)
Maximum lines (default: 10,000)
Maximum heredocs per command (default: 10)
Timeout (default: 50ms)

pub struct ExtractionLimits {
    pub max_body_bytes: usize,
    pub max_body_lines: usize,
    pub max_heredocs: usize,
    pub timeout_ms: u64,
}

Tier 3: AST Pattern Matching (<5ms)

Extracted content is parsed using language-specific AST grammars (via tree-sitter/ast-grep) and matched against structural patterns:

// Example: detect subprocess.run with shell=True and rm -rf
let pattern = r#"
    call_expression {
        function: attribute { object: "subprocess" attr: "run" }
        arguments: argument_list {
            contains string { contains "rm -rf" }
            contains keyword_argument { keyword: "shell" value: "True" }
        }
    }
"#;

Recursive Shell Analysis:

When extracted content is itself a shell script (e.g., bash -c "git reset --hard"), Tier 3 recursively extracts inner commands and re-evaluates them through the full pipeline:

if content.language == ScriptLanguage::Bash {
    let inner_commands = extract_shell_commands(&content.content);
    for inner in inner_commands {
        // Re-evaluate inner command against all packs
        if let Some(result) = evaluate_command(&inner, ...) {
            if result.decision == Deny {
                return result; // Block the outer command
            }
        }
    }
}

If you encounter commands that should be blocked, please file an issue.

Environment Variables

Environment variables override config files (highest priority):

DCG_PACKS="containers.docker,kubernetes": enable packs (comma-separated)
DCG_DISABLE="kubernetes.helm": disable packs/sub-packs (comma-separated)
DCG_VERBOSE=0-3: verbosity level (0 = quiet, 3 = trace)
DCG_QUIET=1: suppress non-error output
DCG_COLOR=auto|always|never: color mode
DCG_NO_RICH=1: disable rich terminal formatting and use plain rendering
DCG_NO_COLOR=1: disable colored output (same as NO_COLOR)
DCG_LEGACY_OUTPUT=1: force plain output paths (same as --legacy-output)
DCG_ROBOT=1: enable robot mode for JSON stdout and quiet stderr
DCG_HIGH_CONTRAST=1: enable high-contrast output (ASCII borders + monochrome palette)
DCG_FORMAT=text|json|sarif: default output format (command-specific — see Output Formats for which values each subcommand actually accepts; real SARIF is dcg scan-only)
DCG_FAIL_CLOSED=1: block (deny) on hook input that cannot be parsed, instead of the default fail-open allow (opt-in; see Fail-Open Philosophy)
DCG_BYPASS=1: bypass dcg entirely (escape hatch; use sparingly)
DCG_CONFIG=/path/to/config.toml: use explicit config file
DCG_HEREDOC_ENABLED=true|false: enable/disable heredoc scanning
DCG_HEREDOC_TIMEOUT=50: heredoc extraction timeout (milliseconds)
DCG_HEREDOC_TIMEOUT_MS=50: heredoc extraction timeout (milliseconds)
DCG_HEREDOC_LANGUAGES=python,bash: filter heredoc languages
DCG_POLICY_DEFAULT_MODE=deny|warn|log: global default decision mode
DCG_HOOK_TIMEOUT_MS=200: hook evaluation timeout budget (milliseconds)

Output Formats and `DCG_FORMAT`

--format (and the DCG_FORMAT env var, which seeds the default) is command-specific: each subcommand accepts only its own set of values, and an unrecognized value is a usage error (exit 2). DCG_FORMAT applies wherever a command has a --format flag and is silently ignored by commands that don’t.

Command	Accepted `--format` values	Notes
`dcg scan`	`pretty`, `json`, `markdown`, `sarif`	Only command that emits real SARIF 2.1.0
`dcg test`	`pretty` (alias `text`), `json` (aliases `sarif`, `structured`), `toon`
`dcg config`	`pretty` (alias `text`), `json` (alias `sarif`)
`dcg packs`	`pretty` (alias `text`), `json` (alias `sarif`)
`dcg explain`	`pretty`, `json` (alias `sarif`)
`dcg doctor`	`pretty`, `json` (alias `sarif`)
`dcg simulate`	`pretty`, `json` (alias `sarif`)
`dcg corpus`	`json`, `pretty` (alias `sarif`)
`dcg suggest-allowlist`	`text`, `json` (alias `sarif`)

sarif is a JSON alias on every command except dcg scan. This is deliberate so that setting DCG_FORMAT=sarif globally degrades gracefully — dcg scan produces a real SARIF report while other commands fall back to their structured JSON rather than erroring. If you need machine-readable output from a non-scan command, prefer --format json (which is unambiguous); use dcg scan --format sarif for SARIF. --robot forces JSON regardless of --format.

Configuration Hierarchy

dcg supports layered configuration from multiple sources, with higher-priority sources overriding lower ones:

Environment Variables (DCG_* prefix) [HIGHEST PRIORITY]
Explicit Config File (DCG_CONFIG env var)
Project Config (.dcg.toml in repo root)
User Config (~/.config/dcg/config.toml)
System Config (/etc/dcg/config.toml)
Compiled Defaults [LOWEST PRIORITY]

Accessibility & Themes

dcg supports colorblind-safe palettes and high-contrast output. Colors are always paired with symbols/labels to avoid conveying meaning by color alone.

[output]
high_contrast = true       # ASCII borders + black/white palette

[theme]
palette = "colorblind"     # default | colorblind | high-contrast
use_unicode = true         # false for ASCII-only
use_color = true           # false for monochrome

Configuration File Locations:

Level	Path	Use Case
System	`/etc/dcg/config.toml`	Organization-wide defaults
User	`~/.config/dcg/config.toml`	Personal preferences
Project	`.dcg.toml` (repo root)	Project-specific settings
Explicit	`DCG_CONFIG=/path/to/file`	Testing or override

Merging Behavior:

Configuration layers are merged additively, with higher-priority sources overriding specific fields:

// Only fields explicitly set in higher-priority configs override
// Missing fields retain values from lower-priority sources
fn merge_layer(&mut self, other: ConfigLayer) {
    if let Some(verbose) = other.general.verbose {
        self.general.verbose = verbose;  // Override if present
    }
    // Unset fields retain previous values
}

This means you can set organization defaults in /etc/dcg/config.toml, personal preferences in ~/.config/dcg/config.toml, and project-specific overrides in .dcg.toml—each layer only needs to specify the settings that differ from defaults.

Project-Specific Pack Configuration:

The [projects] section allows different pack configurations for different repositories:

[projects."/home/user/work/production-api"]
packs = { enabled = ["database.postgresql", "cloud.aws"], disabled = [] }

[projects."/home/user/personal/experiments"]
packs = { enabled = [], disabled = ["core.git"] }  # More permissive for experiments

Fail-Open Philosophy

dcg is designed with a fail-open philosophy: when the tool cannot safely analyze a command (due to timeouts, parse errors, or resource limits), it allows the command to proceed rather than blocking it and breaking the user’s workflow.

Why Fail-Open?

Workflow Continuity: A blocked legitimate command is more disruptive than a missed dangerous one
Performance Guarantees: The hook must never become a bottleneck
Graceful Degradation: Partial analysis is better than no analysis

Fail-Open Scenarios:

Scenario	Behavior	Rationale
Parse error in heredoc	ALLOW + warn	Malformed input shouldn’t block work
Extraction timeout	ALLOW + warn	Slow inputs shouldn’t hang terminal
Size limit exceeded	ALLOW + fallback check	Large inputs get reduced analysis
Regex engine timeout	ALLOW + warn	Pathological patterns shouldn’t block
AST matching error	Skip that heredoc	Continue evaluating other content
Deadline exceeded	ALLOW immediately	Hard cap prevents runaway processing

Configurable Strictness:

For high-security environments, fail-open can be disabled.

For heredoc/inline-script analysis specifically:

1
2
3

[heredoc]
fallback_on_parse_error = false  # Block on heredoc parse errors
fallback_on_timeout = false      # Block on heredoc timeouts

For the top-level hook input (the JSON dcg reads from stdin), enable fail-closed mode so that input which cannot be parsed at all is blocked instead of allowed:

1
2

[general]
fail_closed = true   # Deny when the hook input itself is unparseable

or at runtime:

`1`	`DCG_FAIL_CLOSED=1 # env var overrides the config value`

The default is fail-open (unparseable input is allowed) and is unchanged unless you opt in. With fail-closed enabled, a genuinely unparseable hook payload produces a deny (a permissionDecision: deny for Claude-style hooks; a "decision":"deny" line plus a non-zero exit for dcg hook --batch). Transient IO read errors still fail open even in this mode, since they are not attacker-controlled malformed payloads.

A leading UTF-8 BOM (EF BB BF) is stripped before parsing in all hook paths, so a BOM-prefixed but otherwise-valid command is correctly evaluated (and blocked if dangerous) rather than allowed through as “unparseable”.

With strict mode enabled, dcg will block commands when analysis fails, providing detailed error messages explaining why.

Fallback Pattern Checking:

Even when full analysis is skipped, dcg performs a lightweight fallback check for critical destructive patterns:

static FALLBACK_PATTERNS: LazyLock<RegexSet> = LazyLock::new(|| {
    RegexSet::new([
        r"shutil\.rmtree",
        r"os\.remove",
        r"fs\.rmSync",
        r"\brm\s+-[a-zA-Z]*r[a-zA-Z]*f",
        r"\bgit\s+reset\s+--hard\b",
        // ... other critical patterns
    ])
});

This ensures that even oversized or malformed inputs are checked for the most dangerous operations before being allowed.

Absolute Timeout:

To prevent any single command from blocking indefinitely, dcg enforces an absolute maximum processing time of 200ms. Any command exceeding this threshold is immediately allowed with a warning logged.

Installation

Quick Install (Recommended)

The easiest way to install is using the install script, which downloads a prebuilt binary for your platform:

`1`	`curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" \| bash -s -- --easy-mode`

Easy mode auto-detects your platform, downloads the right binary, verifies SHA256 checksums, configures all supported AI agent hooks (Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, Cursor IDE, Hermes Agent, Aider), and updates your PATH. For Codex CLI 0.125.0+, the installer merges a PreToolUse Bash hook into ~/.codex/hooks.json; invalid JSON or malformed existing Codex hook shapes are left unchanged and reported instead of being overwritten.

Other options:

Interactive mode (prompts for each step):

`1`	`curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" \| bash`

Install specific version:

`1`	`curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" \| bash -s -- --version v0.5.0`

Install to /usr/local/bin (system-wide, requires sudo):

`1`	`curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" \| sudo bash -s -- --system`

Build from source instead of downloading binary:

`1`	`curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" \| bash -s -- --from-source`

Download/install only (skip agent hook configuration):

`1`	`curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" \| bash -s -- --no-configure`

Note: If you have gum installed, the installer will use it for fancy terminal formatting.

The installer also verifies Sigstore cosign bundles when available (falls back to checksum-only), falls back to building from source if no prebuilt is available, and removes the legacy Python predecessor (git_safety_guard.py) if present.

Agent-specific notes

Aider: No PreToolUse-style interception. The installer enables git-commit-verify: true in ~/.aider.conf.yml so git hooks run. For full protection, install dcg as a git pre-commit hook.
Continue: No shell command interception hooks. The installer detects Continue but cannot auto-configure protection. Use a git pre-commit hook instead.
Codex CLI: PreToolUse hooks via ~/.codex/hooks.json (stable in Codex 0.125.0+; the codex_hooks feature is on by default). dcg detects Codex from the turn_id stdin field and emits the minimal documented hookSpecificOutput deny JSON with exit code 0; dcg-only metadata is omitted so Codex’s strict parser accepts the decision. The Unix installer and install.ps1 both merge dcg’s hook into the existing hooks object, detect an already-current dcg hook exactly, leave invalid JSON or malformed hook shapes untouched, and surface the failure reason in the install summary. After installation, open Codex’s /hooks UI once to trust the hook. uninstall.sh and uninstall.ps1 remove only dcg-owned Codex hooks and preserve coexisting entries. See the Codex integration notes. Caveats: the model can still write scripts to disk to bypass hook-based blocking; and Codex’s PreToolUse hooks do not yet intercept every unified_exec shell path, so treat it as a guardrail rather than a complete enforcement boundary.
GitHub Copilot CLI: The installer writes a user-level hook to ${COPILOT_HOME:-~/.copilot}/hooks/dcg.json, protecting every workspace. The generated preToolUse hook covers both Unix bash and Windows powershell payloads and emits Copilot’s exact top-level permission-decision JSON.
VS Code Copilot Chat: Current VS Code releases load ~/.claude/settings.json by default, so the Claude Code hook installed by dcg also protects Copilot Chat without a second bridge or duplicate hook. dcg recognizes VS Code’s documented runTerminalCommand shell tool plus the observed compatibility names run_in_terminal and runInTerminal, reads tool_input.command, and returns VS Code’s documented hookSpecificOutput deny. Agent hooks are still a VS Code preview feature and can be disabled by organization policy; use Developer: Show Agent Debug Logs or the GitHub Copilot Chat Hooks output channel to confirm that the hook loaded.
Cursor IDE: Hooks are configured through ~/.cursor/hooks.json plus a generated bridge (dcg-pre-shell.ps1 on Windows). The installer inserts dcg first in beforeShellExecution, collapses duplicate dcg entries, and preserves coexisting Cursor hooks.
Hermes Agent: NousResearch’s Hermes Agent declares shell hooks in ~/.hermes/config.yaml under hooks.pre_tool_call. The installer merges a single matcher: "terminal" entry that invokes dcg directly — no wrapper script — because Hermes’ input JSON (hook_event_name: "pre_tool_call", tool_name: "terminal", tool_input.command) deserializes straight into dcg’s existing HookInput. Hermes explicitly documents that “non-zero exit codes… never abort the agent loop”, so dcg switches to Hermes’ JSON block protocol on output: {"decision":"block","reason":...} (plus the alternate {"action":"block","message":...} form for cross-version compatibility). The installer also sets hooks_auto_accept: true if not already set; Hermes silently drops un-allowlisted hooks in non-TTY runs (gateway/cron) without it. unconfigure_hermes in uninstall.sh removes only the dcg-owned entry and leaves hooks_auto_accept alone (other Hermes hooks may rely on it).
Grok (xAI): Grok Build / Grok CLI auto-discovers every *.json under ~/.grok/hooks/. dcg install --grok writes a self-contained ~/.grok/hooks/dcg.json with a PreToolUse / matcher: "Bash" entry — Grok internally aliases Claude-style "Bash" to its own run_terminal_cmd tool, so a single rule covers every shell command. dcg detects Grok at runtime from the camelCase wire shape (hookEventName: "pre_tool_use", toolName: "run_terminal_cmd") or from the GROK_SESSION_ID / GROK_HOOK_EVENT / GROK_WORKSPACE_ROOT environment variables, and switches its output to Grok’s JSON contract: {"decision":"deny","reason":...} (note "deny", not Hermes’ "block"). Grok also picks up dcg automatically through its ~/.claude/settings.json compatibility layer, so existing Claude Code users get protection with no additional install step. Add --project to write <repo>/.grok/hooks/dcg.json for a per-repo install (Grok requires /hooks-trust the first time it opens a repo with hooks).
Antigravity CLI (agy): Google Antigravity’s agy CLI ships a Claude-Code-compatible hooks system. dcg install --agy merges a PreToolUse / matcher: "Bash" entry into ~/.gemini/config/hooks.json (the canonical path; agy migrates the legacy ~/.gemini/antigravity-cli/hooks.json here and symlinks the old path to it). agy runs the hook before its run_command shell tool; dcg detects agy at runtime from the distinctive nested toolCall envelope ({"toolCall":{"name":"run_command","args":{"CommandLine":"…"}},"conversationId":…,"stepIdx":…}) — the shell command is read from toolCall.args.CommandLine — or from the ANTIGRAVITY_CONVERSATION_ID environment variable / agy parent-process name. dcg switches its output to agy’s JSON contract: {"decision":"block","reason":…} with exit code 0 (verified: agy honors both "block" and "deny" and aborts the tool; a non-zero exit code is only logged and does NOT reliably block, so dcg always emits exit 0 + JSON). Add --project to write <repo>/.gemini/config/hooks.json for a per-repo install. Restart agy (start a new session) after installing.
OpenCode: Not auto-configured. Requires a Bun-based plugin with "tool.execute.before" hook key. A working community plugin: aspiers/ai-config/dcg-guard.js.
Pi: Not auto-configured. Pi intercepts shell commands through user-authored TypeScript extensions (pi.on("tool_call", …), auto-loaded from ~/.pi/agent/extensions/*.ts or <repo>/.pi/extensions/*.ts). A ready-to-use dcg-guard.ts extension that routes each bash command through dcg --robot test (exit 1 = deny) and blocks with the dcg reason is documented in docs/pi-integration.md.

Recommended: After installing, run dcg setup to add a shell startup check that warns you if the dcg hook is ever silently removed from ~/.claude/settings.json.

From source (requires Rust nightly)

This project uses Rust Edition 2024 features and requires the nightly toolchain. The repository includes a rust-toolchain.toml that automatically selects the correct toolchain.

# Install Rust nightly if you don't have it
rustup install nightly

# Install directly from GitHub
cargo +nightly install --git https://github.com/Dicklesworthstone/destructive_command_guard destructive_command_guard

Manual build

git clone https://github.com/Dicklesworthstone/destructive_command_guard
cd destructive_command_guard
# rust-toolchain.toml automatically selects nightly
cargo build --release
cp target/release/dcg ~/.local/bin/

Updating

Run the built-in updater to re-run the installer for your platform:

`1`	`dcg update`

Optional flags mirror the installer scripts (examples):

1
2
3

dcg update --version v0.2.7
dcg update --system
dcg update --verify

You can always re-run install.sh / install.ps1 directly if preferred.

Prebuilt Binaries

Prebuilt binaries are available for:

Linux x86_64 (x86_64-unknown-linux-gnu)
Linux ARM64 (aarch64-unknown-linux-gnu)
macOS Intel (x86_64-apple-darwin)
macOS Apple Silicon (aarch64-apple-darwin)
Windows x64 (x86_64-pc-windows-msvc)
Windows ARM64 (aarch64-pc-windows-msvc)

Download from GitHub Releases and verify the SHA256 checksum. If you have cosign installed, each release also includes a Sigstore bundle (.sigstore.json) so you can verify provenance with cosign verify-blob.

Uninstalling

Remove dcg and all its hooks from AI agents:

`1`	`curl -fsSL https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/uninstall.sh \| bash`

On Windows:

`1`	`irm https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/uninstall.ps1 \| iex`

The Unix uninstaller:

Removes dcg hooks from Claude Code, Codex CLI, Cursor IDE, Gemini CLI, GitHub Copilot CLI (user-level plus legacy repo-local), Hermes Agent, and Aider
Removes the dcg binary
Removes configuration (~/.config/dcg/) and history (~/.local/share/dcg/)
Prompts for confirmation before making changes

The PowerShell uninstaller removes the Windows dcg.exe binary, the exact User PATH entry added by install.ps1, dcg hooks from Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, Cursor IDE, Hermes Agent, Grok, and Antigravity (agy), plus dcg configuration/history directories.

Options:

--yes - Skip confirmation prompt
--keep-config - Preserve configuration files
--keep-history - Preserve history database
--purge - Remove everything (overrides keep flags)

Claude Code Configuration

Add to ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "dcg"
          }
        ]
      }
    ]
  }
}

Important: Restart Claude Code after adding the hook configuration.

Codex CLI Configuration

Codex CLI 0.125.0+ supports stable PreToolUse hooks. The installer writes or merges this automatically, but the manual configuration lives at ~/.codex/hooks.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "dcg"
          }
        ]
      }
    ]
  }
}

Codex denials intentionally omit dcg’s extended Claude-only fields: dcg exits 0 with the minimal documented hookSpecificOutput JSON on stdout. Allowed commands stay silent with exit code 0.

Gemini CLI Configuration

Add to ~/.gemini/settings.json:

{
  "hooks": {
    "BeforeTool": [
      {
        "matcher": "run_shell_command",
        "hooks": [
          {
            "name": "dcg",
            "type": "command",
            "command": "dcg",
            "timeout": 5000
          }
        ]
      }
    ]
  }
}

Important: Restart Gemini CLI after adding the hook configuration.

CLI Usage

While primarily designed as a hook, the binary supports direct invocation for testing, debugging, and understanding why commands are blocked or allowed.

# Show version with build metadata
dcg --version

# Show help with blocked command categories
dcg --help

# Test a command manually (pipe JSON to stdin)
echo '{"tool_name":"Bash","tool_input":{"command":"git reset --hard"}}' | dcg

Test Mode (`dcg test`)

Use dcg test to evaluate a command without executing it. This is useful for CI checks, false-positive debugging, and config validation before rollout.

Basic Usage

# Basic evaluation (human-readable output)
dcg test "rm -rf ./build"

# Structured output for automation
dcg test --format json "kubectl delete namespace prod" | jq -r .decision

# Use a specific config file
dcg test --config .dcg.prod.toml "docker system prune"

# Temporarily enable extra packs only for this test run
dcg test --with-packs containers.docker,database.postgresql "docker system prune"

# Print full evaluation trace (same engine as `dcg explain`)
dcg test --explain "git reset --hard"

Exit Codes

0: command would be allowed
1: command would be blocked

Flags and Options

-c, --config <PATH>: use a specific config file
--with-packs <ID1,ID2>: temporarily enable extra packs
--explain: print detailed decision trace
-f, --format <pretty|json|toon>: output format (default: pretty)
--no-color: disable ANSI color output
--heredoc-scan: force-enable heredoc/inline-script scanning
--no-heredoc-scan: force-disable heredoc/inline-script scanning
--heredoc-timeout <MS>: override heredoc extraction timeout budget
--heredoc-languages <LANG1,LANG2>: limit heredoc AST scanning languages

Output Formats

pretty: human-readable output with command context, matched rule info, and suggestions
json: structured payload for scripts/CI; includes metadata like schema_version, dcg_version, command, decision, rule/pack fields, and allowlist/agent context when present
toon: token-efficient structured encoding of the same payload used by json (useful for agent-to-agent/tool pipelines)

CI/CD Integration Examples

Fail fast in shell pipelines:

1
2

dcg test --format json "rm -rf /" > /tmp/dcg.json
jq -e '.decision == "allow"' /tmp/dcg.json

Minimal GitHub Actions step:

- name: Validate dangerous command policy
  run: |
    ~/.local/bin/dcg test --format json "git reset --hard HEAD~1" > /tmp/dcg-test.json
    jq -e '.decision == "allow"' /tmp/dcg-test.json

Troubleshooting

Use --format json (or DCG_FORMAT=json) for machine parsing.
Add --no-color if logs or parsers choke on ANSI output.
If results differ between environments, check config precedence (DCG_CONFIG, project .dcg.toml, user/system config).
If a command is unexpectedly allowed, inspect active allowlists (dcg allowlist list) and enabled packs (dcg packs --verbose).
For full decision traces, run dcg test --explain "<command>" (or dcg explain "<command>").

Explain Mode

When you need to understand exactly why a command was blocked (or allowed), the dcg explain command provides a detailed trace of the decision-making process:

# Explain why a command is blocked
dcg explain "git reset --hard HEAD"

# Explain a safe command
dcg explain "git status"

# Explain with verbose timing information
dcg explain --verbose "rm -rf /tmp/build"

# Output as JSON for programmatic use
dcg explain --format json "kubectl delete namespace production"

JSON output is versioned via schema_version (currently 2). v2 adds matched_span, matched_text_preview, and explanation in the match object when a pattern is detected.

Example Output:

Command: git reset --hard HEAD
Normalized: git reset --hard HEAD

Decision: BLOCKED
  Pack: core.git
  Rule: reset-hard
  Reason: git reset --hard destroys uncommitted changes

Evaluation Trace:
  [  0.8μs] Quick reject: passed (contains 'git')
  [  2.1μs] Normalize: no changes
  [  5.3μs] Safe patterns: no match (checked 34 patterns)
  [ 12.7μs] Destructive patterns: MATCH at pattern 'reset-hard'
  [ 12.9μs] Total time: 12.9μs

Suggestion: Consider using 'git stash' first to save your changes.

The explain mode shows:

Normalized command: How dcg sees the command after path normalization
Decision: Whether the command would be blocked or allowed
Matching rule: Which pack and pattern triggered the decision
Evaluation trace: Step-by-step timing of each evaluation stage
Suggestion: Actionable guidance for safer alternatives

This is invaluable for debugging false positives, understanding pack coverage, and verifying that custom allowlist entries work as expected.

Allow-Once (Temporary Exceptions)

Sometimes you need to run a blocked command temporarily without permanently modifying your allowlist. The allow-once system provides short codes:

# When a command is blocked, dcg outputs a short code
# BLOCKED: git reset --hard HEAD
# Allow-once code: 123456
# To allow this: dcg allow-once 123456

# Use the short code to create a temporary exception
dcg allow-once 123456

# Or, use --single-use to make the exception one-shot
dcg allow-once 123456 --single-use

How Allow-Once Works:

When dcg blocks a command, it generates a short code (currently 6 numeric digits; collisions are handled via --pick / --hash)
The code is tied to the exact command that was blocked
Running dcg allow-once <code> creates a temporary exception
The exception is stored in ~/.config/dcg/pending_exceptions.jsonl
Exceptions expire after 24 hours (or after first use if --single-use is used)
While active, the exception allows the same command in the same directory scope

This workflow is useful for:

One-time administrative operations that are intentionally destructive
Migration scripts that need to reset state
Emergency fixes where permanent allowlist changes aren’t appropriate

Security Considerations:

Short codes are derived from SHA256 (or optional HMAC-SHA256 when DCG_ALLOW_ONCE_SECRET is set)
Codes are never logged or transmitted
The pending exceptions file is readable only by the current user
Expired codes are automatically cleaned up

Rebase Recovery Mode

AI coding agents routinely get stuck when git pull --rebase fails partway — unstaged-changes errors, stash-pop conflicts, interrupted rebases. The documented recovery path is almost always git checkout -- . or git restore <paths>, both of which dcg hard-blocks (core.git:checkout-discard, core.git:restore-worktree). Agents then have to stop and ask a human to run the command manually.

Rebase-recovery mode is a narrow, bounded relaxation of those two rules that only fires under a genuine recovery signal. Outside that signal the default block is unchanged.

Two complementary signals unlock recovery:

Active rebase state (automatic, zero-config). When .git/rebase-merge/ or .git/rebase-apply/ exists, a rebase is in progress and the discard operations are the documented recovery path. dcg detects this state and converts the deny into an allow with a [dcg] Allowing ... → rebase-recovery mode note on stderr. No permit needed.
Explicit permit cookie (opt-in, short-lived). When the rebase already finished but the worktree is still messy (e.g. after a bad git stash pop), run:
1 2

dcg rebase-recover # default ttl: 120s dcg rebase-recover --ttl 60 # custom ttl (max: 600s)
This writes a timestamp to .dcg/rebase-recovery-permit at the repo root. For the next N seconds (or until the first matching allow, whichever comes first), git checkout -- <path> and git restore <paths> are allowed. The permit is single-shot — one successful allow consumes it — so it can’t silently unblock later unrelated commands within the TTL.

Scope and safety guarantees:

Only four rules participate: core.git:checkout-discard, core.git:checkout-ref-discard, core.git:restore-worktree, core.git:restore-worktree-explicit.
Nothing else is affected. git reset --hard, git clean -f, git push --force, etc. stay blocked even during an active rebase or with a permit active.
The permit is scoped to the current repo’s .dcg/ directory. It does not cross repos.
Expired permits are auto-cleaned on the next check.

Typical recovery flow:

$ git pull --rebase
# ... fails with "unstaged changes" ...
$ git stash
$ git pull --rebase        # succeeds
$ git stash pop            # leaves messy worktree
$ git checkout -- .
BLOCKED by dcg  (core.git:checkout-discard)
  ... Recovering from a failed `git pull --rebase`?
  ... Run `dcg rebase-recover` in this repo, then retry the command.
$ dcg rebase-recover
dcg rebase-recovery permit issued ...
$ git checkout -- .        # now allowed, permit consumed
$ git push

See issue #104 for background.

The --version output includes build metadata for debugging:

dcg 0.1.0
  Built: 2026-01-07T22:13:10.413872881Z
  Rustc: 1.94.0-nightly
  Target: x86_64-unknown-linux-gnu

This metadata is embedded at compile time via vergen, making it easy to identify exactly which build is running when troubleshooting.

Repository Scanning

While the hook protects interactive command execution, teams also need protection against destructive commands that get committed into repositories. The dcg scan command extracts executable command contexts from files and evaluates them using the same pattern engine.

What Scan Is (and Is Not)

What it is:

An extractor-based scanner that understands executable contexts
Uses the same evaluator as hook mode for consistency
Supports CI integration and pre-commit hooks

What it is NOT:

A naive grep that matches strings everywhere
A replacement for code review
A static analysis tool for arbitrary languages

The key difference from grep: dcg scan understands that "rm -rf /" in a comment is data, not code. It uses extractors that understand file structure (shell scripts, Dockerfiles, CI workflows, package scripts, Makefiles, Terraform, Docker Compose) to find only actually-executed commands.

Supported File Formats

dcg scan includes specialized extractors for each file format, understanding which parts contain executable commands:

File Type	Detection	Executable Contexts
Shell Scripts	`.sh`, `.bash`, `.zsh`, `.dash`, `*.ksh`	Non-comment executable command lines
Dockerfile	`Dockerfile`, `Dockerfile.`, `.dockerfile`	`RUN` instructions (shell and exec forms)
GitHub Actions	`.github/workflows/.yml`, `.github/workflows/.yaml`	`run:` fields in steps
GitLab CI	`.gitlab-ci.yml`, `*.gitlab-ci.yml`	`script:`, `before_script:`, `after_script:`
Azure Pipelines	`azure-pipelines.yml`, `azure-pipelines.yaml`, `azure-pipelines-.yml`, `azure-pipelines-.yaml`	`script:`, `bash:`, `powershell:`, `pwsh:` tasks
CircleCI	`.circleci/config.yml`, `.circleci/config.yaml`	`run:` steps and nested `command:` fields
Makefile	`Makefile`	Tab-indented recipe lines
package.json	`package.json`	`scripts` object values
Terraform	`*.tf`	`provisioner` blocks (`local-exec`, `remote-exec`)
Docker Compose	`docker-compose.yml`, `docker-compose.yaml`, `compose.yml`, `compose.yaml`	`command:`, `entrypoint:`, `healthcheck.test:` fields
PowerShell	`.ps1`, `.psm1`, `*.psd1`	Executable statements with line and block comments excluded
Batch Scripts	`.cmd`, `.bat`	Executable command lines with comments excluded

Context-Aware Extraction:

Each extractor understands its format’s semantics:

# GitHub Actions - only 'run:' is extracted
- name: Build
  run: |                    # ← Extracted
    npm install
    npm run build
  env:
    NODE_ENV: production    # ← Skipped (not executable)

# Dockerfile - only RUN instructions
FROM node:18
COPY . /app                 # ← Skipped
RUN npm install             # ← Extracted
RUN ["node", "server.js"]   # ← Extracted (exec form)
ENV PORT=3000               # ← Skipped

# Makefile - tab-indented lines under targets
build:
	npm install             # ← Extracted (recipe line)
	npm run build           # ← Extracted
SOURCES = $(wildcard *.js)  # ← Skipped (variable assignment)

Non-Executable Context Filtering:

Extractors intelligently skip data-only sections:

Shell: Assignment-only lines (export VAR=value)
YAML: environment:, labels:, volumes:, variables: blocks
Terraform: Everything outside provisioner blocks
All formats: Comments (format-appropriate: #, //, etc.)

Quick Start

# Install the pre-commit hook
dcg scan install-pre-commit

# Or manually run on staged files
dcg scan --staged

# Scan specific paths
dcg scan --paths scripts/ .github/workflows/

Recommended Rollout Plan

Start conservative to avoid developer friction:

1
2

# Week 1-2: Warn-first with narrow scope
dcg scan --staged --fail-on error  # Only fail on catastrophic rules

Create .dcg/hooks.toml with conservative defaults:

[scan]
fail_on = "error"          # Only fail on high-confidence catastrophic rules
format = "pretty"          # Human-readable output
redact = "quoted"          # Hide sensitive strings
truncate = 120             # Shorten long commands

[scan.paths]
include = [
    ".github/workflows/**",  # Start with CI configs
    "Dockerfile",            # Container builds
    "Makefile",              # Build scripts
]
exclude = [
    "target/**",
    "node_modules/**",
    "vendor/**",
]

Gradual expansion:

Week 1-2: Start with workflows/Dockerfiles only, --fail-on error
Week 3-4: Add Makefiles and shell scripts in scripts/
Month 2: Add --fail-on warning after reviewing findings
Ongoing: Add new extractors as team confidence grows

Pre-Commit Integration

One-Command Install

`1`	`dcg scan install-pre-commit`

This creates a .git/hooks/pre-commit that runs dcg scan --staged.

Manual Setup

If you prefer manual control or use a hook manager:

#!/bin/bash
# .git/hooks/pre-commit (or equivalent for your hook manager)

set -e

# Run dcg scan on staged files
dcg scan --staged --fail-on error

# Add other hooks below...

Uninstall

`1`	`dcg scan uninstall-pre-commit`

This only removes hooks installed by dcg (detected via sentinel comment).

Interpreting Findings

The output includes:

scripts/deploy.sh:42:5: [ERROR] core.git:reset-hard
  Command: git reset --hard HEAD
  Reason: git reset --hard destroys uncommitted changes
  Suggestion: Consider using 'git stash' first to save changes.

File:Line:Col: Location in the source file
Severity: ERROR (catastrophic) or WARNING (concerning)
Rule ID: Stable identifier like core.git:reset-hard
Command: The extracted command (may be redacted/truncated)
Reason: Why this command is flagged
Suggestion: How to make it safer

Fixing Findings

Option 1: Change the Code (Preferred)

Replace the dangerous command with a safer alternative:

# Instead of:
git reset --hard

# Use:
git stash push -m "before reset"
git reset --hard

Option 2: Understand with Explain

Get detailed analysis:

`1`	`dcg explain "git reset --hard HEAD"`

Option 3: Allowlist (When Intentional)

If the command is genuinely needed:

# Project-level allowlist (committed, code-reviewed)
dcg allowlist add core.git:reset-hard --reason "Required for CI cleanup" --project

# Or for a specific command
dcg allowlist add-command "rm -rf ./build" --reason "Build cleanup" --project

The finding output includes a copy-paste allowlist command for convenience. Heredoc rules use stable IDs like heredoc.python.shutil_rmtree.

Privacy and Redaction

Scan supports redaction of potentially sensitive content in output. Use --redact quoted to hide quoted strings that may contain secrets:

# Original command:
curl -H "Authorization: Bearer $TOKEN" https://api.example.com

# With --redact quoted:
curl -H "..." https://api.example.com

Options:

--redact none: Show full commands (default)
--redact quoted: Hide quoted strings (recommended for CI logs)
--redact aggressive: Hide more potential secrets

Configuration Reference

.dcg/hooks.toml (project-level, committed):

[scan]
# Exit non-zero when findings meet this threshold
fail_on = "error"      # Options: none, warning, error

# Output format
format = "pretty"      # Options: pretty, json, markdown

# Maximum file size to scan (bytes)
max_file_size = 1000000

# Stop after this many findings
max_findings = 50

# Redaction level for sensitive content
redact = "quoted"      # Options: none, quoted, aggressive

# Truncate long commands (chars; 0 = no truncation)
truncate = 120

[scan.paths]
# Only scan files matching these patterns
include = [
    "scripts/**",
    ".github/workflows/**",
    "Dockerfile*",
    "Makefile",
]

# Skip files matching these patterns
exclude = [
    "target/**",
    "node_modules/**",
    "*.md",
]

CLI flags override config file values.

CI Integration

GitHub Actions

name: Security Scan
on: [pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install dcg
        run: |
          curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh" | bash
          echo "$HOME/.local/bin" >> $GITHUB_PATH

      - name: Scan changed files
        run: |
          dcg scan --git-diff origin/${{ github.base_ref }}..HEAD \
            --format markdown \
            --fail-on error

GitLab CI

scan:
  stage: test
  script:
    - curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh" | bash
    - ~/.local/bin/dcg scan --git-diff origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME..HEAD --fail-on error
  rules:
    - if: $CI_MERGE_REQUEST_ID

Bypass for Emergencies

If you need to bypass the pre-commit hook temporarily:

`1`	`git commit --no-verify -m "Emergency fix"`

This is logged and visible in git history. For permanent exceptions, use allowlists instead.

How It Works

Your AI agent invokes dcg as a PreToolUse hook before executing each shell command. The hook receives the command as JSON on stdin and runs through a four-stage pipeline:

JSON Parsing – Validates the hook payload (Claude/Gemini/Copilot variants), extracts the command string. Non-shell tools are immediately allowed.
Normalization – Strips absolute paths (/usr/bin/git becomes git) while preserving arguments.
Quick Reject – O(n) substring search for keywords like “git” or “rm”. Commands without these substrings skip regex matching entirely (handles 99%+ of non-destructive commands).
Pattern Matching – Safe patterns checked first (match = allow). Destructive patterns checked second (match = deny with explanation). No match on either = allow.

If blocked under a Claude-compatible JSON hook protocol, dcg outputs a JSON denial on stdout and a colorful human-readable warning on stderr. If blocked under Codex CLI, dcg follows Codex’s strict hook contract with minimal stdout JSON and exit code 0. If allowed, dcg exits silently. Rich formatting is automatically disabled for CI, non-TTY output, dumb terminals, and no-color environments.

Architecture

┌─────────────────────────────────────────────────────────────────┐
│   Claude / Codex / Gemini / Copilot / Cursor / Hermes hooks      │
│                                                                  │
│  User: "delete the build artifacts"                             │
│  Agent: executes `rm -rf ./build`                               │
│                                                                  │
└─────────────────────┬───────────────────────────────────────────┘
                      │
                      ▼ PreToolUse hook (stdin: JSON)
┌─────────────────────────────────────────────────────────────────┐
│                     dcg                             │
│                                                                  │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐       │
│  │    Parse     │───▶│  Normalize   │───▶│ Quick Reject │       │
│  │    JSON      │    │   Command    │    │   Filter     │       │
│  └──────────────┘    └──────────────┘    └──────┬───────┘       │
│                                                  │               │
│                      ┌───────────────────────────┘               │
│                      ▼                                           │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                   Pattern Matching                        │   │
│  │                                                           │   │
│  │   1. Check SAFE_PATTERNS (whitelist) ──▶ Allow if match  │   │
│  │   2. Check DESTRUCTIVE_PATTERNS ──────▶ Deny if match    │   │
│  │   3. No match ────────────────────────▶ Allow (default)  │   │
│  │                                                           │   │
│  └──────────────────────────────────────────────────────────┘   │
│                                                                  │
└─────────────────────┬───────────────────────────────────────────┘
                      │
                      ▼ stdout: JSON deny / empty allow
                        stderr: rich human output / Codex deny reason
┌─────────────────────────────────────────────────────────────────┐
│   Claude / Codex / Gemini / Copilot / Cursor / Hermes hooks      │
│                                                                  │
│  If denied: Shows block message, does NOT execute command       │
│  If allowed: Proceeds with command execution                    │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Context Classification System

Not every occurrence of a dangerous pattern is actually dangerous. The string git reset --hard appearing in a comment, a heredoc body, or a quoted string is fundamentally different from the same string appearing as an executed command. dcg uses a sophisticated context classification system to reduce false positives without compromising safety.

SpanKind Classification

Every token in a command is classified into one of these categories:

SpanKind	Description	Treatment
`Executed`	Command words and unquoted arguments	MUST check - highest priority
`InlineCode`	Content inside `-c`/`-e` flags (bash -c, python -c)	MUST check - code will be executed
`Argument`	Quoted arguments to known-safe commands	Lower priority, context-dependent
`Data`	Single-quoted strings (shell cannot interpolate)	Can skip - treated as literal data
`HeredocBody`	Content inside heredocs	Escalated to Tier 2/3 heredoc scanning
`Comment`	Shell comments (`# ...`)	Skip - never executed
`Unknown`	Cannot determine context	Conservative treatment as `Executed`

Why Context Matters

Consider these commands:

# Safe: the dangerous pattern is in a comment
echo "Reminder: never run git reset --hard"   # git reset --hard destroys changes

# Safe: the dangerous pattern is data being searched for
grep "git reset --hard" documentation.md

# Safe: the dangerous pattern is in a heredoc being written to a file
cat <<EOF > safety_guide.md
Warning: git reset --hard destroys uncommitted changes
EOF

# DANGEROUS: the pattern will be executed
git reset --hard HEAD

# DANGEROUS: the pattern is passed to bash -c for execution
bash -c "git reset --hard"

Without context classification, the first three examples would trigger false positives. The context classifier analyzes the AST (abstract syntax tree) structure to understand where patterns appear and only flags genuinely dangerous occurrences.

Implementation Details

The context classifier uses a multi-pass approach:

Lexical Analysis: Identify quoted strings, comments, and heredoc markers
Structural Analysis: Build a tree of command structure, identifying pipes, subshells, and command substitutions
Flag Analysis: Detect -c, -e, and similar flags that introduce inline code contexts
Span Annotation: Tag each character range with its SpanKind

This approach achieves a significant reduction in false positives while maintaining the zero-false-negatives philosophy for actual command execution.

Design Principles

1. Whitelist-First Architecture

Safe patterns are checked before destructive patterns. This design ensures that explicitly safe commands (like git checkout -b) are never accidentally blocked, even if they partially match a destructive pattern (like git checkout).

1
2

git checkout -b feature    →  Matches SAFE "checkout-new-branch"  →  ALLOW
git checkout -- file.txt   →  No safe match, matches DESTRUCTIVE  →  DENY

2. Fail-Safe Defaults

The hook uses a default-allow policy for unrecognized commands. This ensures:

The hook never breaks legitimate workflows
Only known dangerous patterns are blocked
New git commands are allowed until explicitly categorized

3. Zero False Negatives Philosophy

The pattern set prioritizes never allowing dangerous commands over avoiding false positives. A few extra prompts for manual confirmation are acceptable; lost work is not.

4. Defense in Depth

This hook is one layer of protection. It complements (not replaces):

Regular commits and pushes
Git stash before risky operations
Proper backup strategies
Code review processes

5. Minimal Latency

Every Bash command passes through this hook. Performance is critical:

Lazy-initialized static regex patterns (compiled once, reused)
Quick rejection filter eliminates 99%+ of commands before regex
No heap allocations on the hot path for safe commands
Sub-millisecond execution for typical commands

Pattern Matching System

Safe Patterns (Whitelist)

The safe pattern list contains 34 patterns covering:

Category	Patterns	Purpose
Branch creation	`checkout -b`, `checkout --orphan`	Creating branches is safe
Staged-only	`restore --staged`, `restore -S`	Unstaging doesn’t touch working tree
Dry run	`clean -n`, `clean --dry-run`	Preview mode, no actual deletion
Temp cleanup	`rm -rf /tmp/`, `rm -rf /var/tmp/`	Ephemeral directories are safe
Variable expansion	`rm -rf $TMPDIR/`, `rm -rf ${TMPDIR}/`	Shell variable forms
Quoted paths	`rm -rf "$TMPDIR/*"`	Quoted variable forms
Separate flags	`rm -r -f /tmp/`, `rm -r -f $TMPDIR/`	Flag ordering variants
Long flags	`rm --recursive --force /tmp/`, `$TMPDIR/`	GNU-style long options

Destructive Patterns (Blacklist)

The destructive pattern list contains 16 patterns covering:

Category	Pattern	Reason
Work destruction	`reset --hard`, `reset --merge`	Destroys uncommitted changes
File reversion	`checkout -- <path>`	Discards file modifications
Worktree restore	`restore` (without –staged)	Discards uncommitted changes
Untracked deletion	`clean -f`	Permanently removes untracked files
History rewrite	`push --force`, `push -f`	Can destroy remote commits
Unsafe branch delete	`branch -D`	Force-deletes without merge check
Stash destruction	`stash drop`, `stash clear`	Permanently deletes stashed work
Filesystem nuke	`rm -rf` (non-temp paths)	Recursive deletion outside temp

Pattern Syntax

Patterns use fancy-regex for advanced features:

// Negative lookahead: block restore UNLESS --staged is present
r"git\s+restore\s+(?!--staged\b)(?!-S\b)"

// Negative lookahead: don't match --force-with-lease
r"git\s+push\s+.*--force(?![-a-z])"

// Character class: match any flag ordering
r"rm\s+-[a-zA-Z]*[rR][a-zA-Z]*f[a-zA-Z]*"

Edge Cases Handled

Path Normalization

Commands may use absolute paths to binaries:

1
2
3

/usr/bin/git reset --hard          # Blocked ✓
/usr/local/bin/git checkout -- .   # Blocked ✓
/bin/rm -rf /home/user             # Blocked ✓

The normalizer uses regex to strip paths while preserving arguments:

`1`	`git add /usr/bin/something # "/usr/bin/something" is an argument, preserved`

Flag Ordering Variants

The rm command accepts flags in many forms:

rm -rf /path          # Combined flags
rm -fr /path          # Reversed order
rm -r -f /path        # Separate flags
rm -f -r /path        # Separate, reversed
rm --recursive --force /path    # Long flags
rm --force --recursive /path    # Long flags, reversed
rm -rf --no-preserve-root /     # Additional flags

All variants are handled by flexible regex patterns.

Shell Variable Expansion

Temp directory variables come in multiple forms:

rm -rf $TMPDIR/build           # Unquoted, simple
rm -rf ${TMPDIR}/build         # Unquoted, braced
rm -rf "$TMPDIR/build"         # Quoted, simple
rm -rf "${TMPDIR}/build"       # Quoted, braced
rm -rf "${TMPDIR:-/tmp}/build" # With default value

Git Flag Combinations

Git commands can have flags in various positions:

git push --force                  # Blocked ✓
git push origin main --force      # Blocked ✓
git push --force origin main      # Blocked ✓
git push -f                       # Blocked ✓
git push --force-with-lease       # Allowed ✓ (safe alternative)

Staged vs Worktree Restore

The restore command has nuanced safety:

git restore --staged file.txt           # Allowed ✓ (unstaging only)
git restore -S file.txt                 # Allowed ✓ (short flag)
git restore file.txt                    # Blocked (discards changes)
git restore --worktree file.txt         # Blocked (explicit worktree)
git restore --staged --worktree file    # Blocked (includes worktree)
git restore -S -W file.txt              # Blocked (includes worktree)

Performance Optimizations

Dual Regex Engine Architecture

dcg uses a sophisticated dual-engine regex system that automatically selects the optimal engine for each pattern. This enables both guaranteed performance and advanced pattern matching features.

The Two Engines:

Engine	Crate	Time Complexity	Features	Use Case
Linear	`regex`	O(n) guaranteed	Basic regex, character classes, alternation	~85% of patterns
Backtracking	`fancy_regex`	O(2^n) worst case	Lookahead, lookbehind, backreferences	~15% of patterns

Automatic Engine Selection:

When a pattern is compiled, dcg analyzes it to determine which engine to use:

pub enum CompiledRegex {
    Linear(regex::Regex),           // O(n) guaranteed, no lookahead
    Backtracking(fancy_regex::Regex), // Supports lookahead/lookbehind
}

impl CompiledRegex {
    pub fn new(pattern: &str) -> Result<Self, Error> {
        // Try linear engine first (faster, predictable)
        if let Ok(re) = regex::Regex::new(pattern) {
            return Ok(CompiledRegex::Linear(re));
        }
        // Fall back to backtracking for advanced features
        Ok(CompiledRegex::Backtracking(fancy_regex::Regex::new(pattern)?))
    }
}

Why This Matters:

Performance predictability: The linear engine guarantees O(n) matching time, critical for a hook that runs on every command
Feature completeness: Some patterns require negative lookahead (e.g., “match --force but not --force-with-lease”)
Automatic optimization: Pattern authors don’t need to think about engine selection—dcg chooses optimally

Examples of Engine Selection:

// Linear engine (simple pattern)
r"git\s+reset\s+--hard"              // No advanced features needed

// Backtracking engine (negative lookahead)
r"git\s+push\s+.*--force(?![-a-z])"  // Must NOT be followed by "-with-lease"

// Linear engine (character classes)
r"rm\s+-[a-zA-Z]*[rR][a-zA-Z]*f"     // Complex but no lookahead

Performance Budget System

dcg operates under strict latency constraints - every Bash command passes through the hook, so even small delays compound into noticeable sluggishness. src/perf.rs is the source of truth for performance budgets, CI benchmark expectations, and hook-mode fail-open deadlines.

Latency Tiers:

Tier	Path	Target	Warning Above	Panic Above
0	Quick reject	< 1μs	> 5μs	> 50μs
1	Fast path	< 75μs	> 150μs	> 500μs
2	Pattern match	< 100μs	> 250μs	> 1ms
3	Heredoc trigger	< 5μs	> 10μs	> 100μs
4	Heredoc extract	< 200μs	> 500μs	> 2ms
5	Language detect	< 20μs	> 50μs	> 200μs
6	Full heredoc pipeline	< 5ms	> 15ms	> 20ms

Hook mode also has an absolute 200ms deadline. If that deadline is exhausted, expensive analysis fails open so dcg does not hang an interactive workflow.

Fail-Open Behavior:

If any stage exceeds its panic threshold, dcg logs a warning and allows the command:

1
2

[WARN] Performance budget exceeded: Tier 2 (safe patterns) took 1.2ms (panic threshold: 500μs)
[WARN] Failing open to avoid blocking workflow

This design ensures that:

A pathological input cannot hang the user’s terminal
Performance regressions are visible in logs
The tool never becomes a productivity bottleneck

Budget Enforcement:

let deadline = Deadline::fail_open_default();

if deadline.is_exceeded() || !deadline.has_budget_for(&PATTERN_MATCH) {
    return EvaluationResult::allowed_due_to_budget();
}

Monitoring Performance:

Use dcg explain --verbose to see per-stage timing:

Evaluation Trace:
  [  0.3μs] Tier 0: Quick reject (PASS - below 1μs target)
  [  8.7μs] Tier 1: Fast path (PASS - below 75μs target)
  [ 15.2μs] Tier 2: Pattern match (PASS - below 100μs target)
  [ 15.4μs] Total: 15.4μs (PASS - below 5ms target)

Keyword-Based Pack Pre-filtering

Before expensive regex matching, dcg uses a multi-level keyword filtering system to quickly skip irrelevant packs. This is critical for performance—with 50+ packs available, checking every pattern against every command would be prohibitively slow.

How Keyword Filtering Works:

Each pack declares a set of keywords that must appear in a command for that pack to be relevant:

Pack {
    id: "database.postgresql".to_string(),
    keywords: &["psql", "dropdb", "createdb", "DROP", "TRUNCATE", "DELETE"],
    // ...
}

Two-Level Filtering:

Global Quick Reject: Before any pack evaluation, dcg checks if the command contains any keyword from any enabled pack. If not, the entire pack evaluation is skipped.
Per-Pack Quick Reject: For each enabled pack, dcg checks if the command contains any of that pack’s keywords before running expensive regex patterns.

Aho-Corasick Automaton:

For packs with multiple keywords, dcg builds an Aho-Corasick automaton that matches all keywords in a single O(n) pass:

// Built lazily on first pack access
pub keyword_matcher: Option<aho_corasick::AhoCorasick>,

pub fn might_match(&self, cmd: &str) -> bool {
    if self.keywords.is_empty() {
        return true; // No keywords = always check patterns
    }

    // O(n) matching regardless of keyword count
    if let Some(ref ac) = self.keyword_matcher {
        return ac.is_match(cmd);
    }

    // Fallback: sequential memchr search
    self.keywords.iter()
        .any(|kw| memmem::find(cmd.as_bytes(), kw.as_bytes()).is_some())
}

Context-Aware Keyword Matching:

Keywords are only matched within executable spans (not in comments, quoted strings, or data):

pub fn pack_aware_quick_reject(cmd: &str, enabled_keywords: &[&str]) -> bool {
    // First: fast substring check
    let any_substring = enabled_keywords.iter()
        .any(|kw| memmem::find(cmd.as_bytes(), kw.as_bytes()).is_some());

    if !any_substring {
        return true; // Safe to skip all pack evaluation
    }

    // Second: verify keyword appears in executable context
    let spans = classify_command(cmd);
    for span in spans.executable_spans() {
        if span_matches_any_keyword(span.text(cmd), enabled_keywords) {
            return false; // Must evaluate packs
        }
    }

    true // Keywords only in non-executable contexts, safe to skip
}

This approach ensures that a command like echo "psql" | grep DROP doesn’t trigger PostgreSQL pack evaluation just because keywords appear in the data being processed.

1. Lazy Static Initialization

Regex patterns are compiled once on first use via LazyLock:

static SAFE_PATTERNS: LazyLock<Vec<Pattern>> = LazyLock::new(|| {
    vec![
        pattern!("checkout-new-branch", r"git\s+checkout\s+-b\s+"),
        // ... 33 more patterns
    ]
});

Subsequent invocations reuse the compiled patterns with zero compilation overhead.

2. SIMD-Accelerated Quick Rejection

Before any regex matching, a SIMD-accelerated substring search filters out irrelevant commands. The memchr crate uses CPU vector instructions (SSE2, AVX2, NEON) when available:

use memchr::memmem;

static GIT_FINDER: LazyLock<memmem::Finder<'static>> = LazyLock::new(|| memmem::Finder::new("git"));
static RM_FINDER: LazyLock<memmem::Finder<'static>> = LazyLock::new(|| memmem::Finder::new("rm"));

fn quick_reject(cmd: &str) -> bool {
    let bytes = cmd.as_bytes();
    GIT_FINDER.find(bytes).is_none() && RM_FINDER.find(bytes).is_none()
}

For commands like ls -la, cargo build, or npm install, this check short-circuits the entire matching pipeline. The memmem::Finder is pre-compiled once and reused, avoiding repeated setup costs.

3. Early Exit on Safe Match

Safe patterns are checked first. On match, the function returns immediately without checking destructive patterns:

for pattern in SAFE_PATTERNS.iter() {
    if pattern.regex.is_match(&normalized).unwrap_or(false) {
        return;  // Allow immediately
    }
}

4. Compile-Time Pattern Validation

The pattern! and destructive! macros include the pattern name in panic messages, making invalid patterns fail at first execution with clear diagnostics:

macro_rules! pattern {
    ($name:literal, $re:literal) => {
        Pattern {
            regex: Regex::new($re).expect(concat!("pattern '", $name, "' should compile")),
            name: $name,
        }
    };
}

5. Zero-Copy JSON Parsing

The serde_json parser operates on the input buffer without unnecessary copies. The command string is extracted directly from the parsed JSON value.

6. Zero-Allocation Path Normalization

Command normalization uses Cow<str> (copy-on-write) to avoid heap allocations in the common case:

fn normalize_command(cmd: &str) -> Cow<'_, str> {
    // Fast path: if command doesn't start with '/', no normalization needed
    if !cmd.starts_with('/') {
        return Cow::Borrowed(cmd);  // Zero allocation
    }
    PATH_NORMALIZER.replace(cmd, "$1")  // Allocation only when path is stripped
}

Most commands don’t use absolute paths to git or rm, so this fast path avoids allocation entirely for 99%+ of inputs.

7. Release Profile Optimization

The release build uses aggressive optimization settings:

[profile.release]
opt-level = "z"     # Optimize for size (lean binary)
lto = true          # Link-time optimization across crates
codegen-units = 1   # Single codegen unit for better optimization
panic = "abort"     # Smaller binary, no unwinding overhead
strip = true        # Remove debug symbols

Example Block Message

When a destructive command is intercepted, the hook outputs a colorful warning to stderr (shown below without ANSI codes):

════════════════════════════════════════════════════════════════════════
BLOCKED  dcg
────────────────────────────────────────────────────────────────────────
Reason:  git reset --hard destroys uncommitted changes. Use 'git stash' first.

Command:  git reset --hard HEAD~1

Tip: If you need to run this command, execute it manually in a terminal.
     Consider using 'git stash' first to save your changes.
════════════════════════════════════════════════════════════════════════

Output Modes

dcg separates agent-facing data from human-facing display. This lets agents parse stable output while people watching the terminal still get readable, high-signal formatting.

Mode	Trigger	stdout	stderr
Hook allow	Safe command	Empty	Empty
JSON-hook deny	Claude Code, Gemini CLI, Copilot CLI, VS Code Copilot Chat, compatible hooks	Denial JSON	Rich or plain warning
Hermes block	Hermes Agent shell hook (`pre_tool_call`)	`{"decision":"block","reason":...,"action":"block","message":...}`	Rich or plain warning
Grok deny	Grok (xAI) PreToolUse hook (`pre_tool_use` event, `run_terminal_cmd` tool)	`{"decision":"deny","reason":...}` (exit 0)	Rich or plain warning
Antigravity block	Antigravity CLI (`agy`) PreToolUse hook (`toolCall.name: "run_command"`)	`{"decision":"block","reason":...}` (exit 0)	Rich or plain warning
Codex deny	Codex CLI 0.144.x hook input	Minimal `hookSpecificOutput` deny JSON	Deny reason with command, rule, and remediation
Robot mode	`--robot` or `DCG_ROBOT=1`	JSON	Silent
Plain fallback	`DCG_NO_RICH=1`, `NO_COLOR=1`, `DCG_NO_COLOR=1`, `TERM=dumb`, `CI=1`, non-TTY output, or `--legacy-output`	Mode-specific data	Plain text only

Rich Human Output

Rich output is for humans and always belongs on stderr. It includes the blocked command, severity, rule id, pack id, explanation, and safer alternatives when available:

BLOCKED  dcg
Reason:  git reset --hard destroys uncommitted changes
Rule:    core.git:reset-hard
Command: git reset --hard HEAD~1
Tip:     Use git stash to save your changes first.

Plain and No-Color Output

Use plain output for logs, terminals with limited capabilities, or tests that assert exact strings:

1
2
3

DCG_NO_RICH=1 dcg test "git reset --hard HEAD"
NO_COLOR=1 dcg explain "rm -rf ./build"
TERM=dumb dcg scan .

Build Features

Rich terminal output is enabled by default. For a lean build without the rich_rust dependency, compile with:

`1`	`cargo build --release --no-default-features`

Agent JSON Output

For automation, prefer robot mode or the hook protocol your agent expects:

# Robot-mode scripting: parse stdout JSON, ignore stderr.
dcg --robot test "rm -rf /" >decision.json 2>/dev/null

# Claude-compatible hook integration: parse stdout only when non-empty.
dcg < hook-input.json >hook-output.json 2>human-warning.txt

Codex integrations should parse the minimal stdout JSON; empty stdout with exit code 0 means allow.

Suggestion System

dcg doesn’t just block commands—it provides actionable guidance to help users make safer choices. The suggestion system generates context-aware recommendations based on the specific command that was blocked.

Suggestion Categories:

Category	Purpose	Example
`PreviewFirst`	Run a dry-run/preview command first	“Run `git clean -n` first to preview deletions”
`SaferAlternative`	Use a safer command that achieves similar goals	“Use `--force-with-lease` instead of `--force`”
`WorkflowFix`	Fix the workflow to avoid the dangerous operation	“Commit your changes before resetting”
`Documentation`	Link to relevant documentation	“See `man git-reset` for reset options”
`AllowSafely`	How to allowlist if the operation is intentional	“Add to allowlist: `dcg allowlist add core.git:reset-hard`”

Contextual Suggestions by Command Type:

Command Type	Suggestion
`git reset`, `git checkout --`	“Consider using ‘git stash’ first to save your changes.”
`git clean`	“Use ‘git clean -n’ first to preview what would be deleted.”
`git push --force`	“Consider using ‘–force-with-lease’ for safer force pushing.”
`rm -rf`	“Verify the path carefully before running rm -rf manually.”
`kubectl delete`	“Use `kubectl delete --dry-run=client` to preview deletions.”
`docker system prune`	“Run with `--dry-run` first to see what would be removed.”
`DROP TABLE`	“Consider `TRUNCATE` if you only need to remove data, not the schema.”

Custom Suggestions in Packs:

Each destructive pattern can specify its own suggestion tailored to the specific operation:

destructive_pattern!(
    "restic-forget",
    r"restic(?:\s+--?\S+(?:\s+\S+)?)*\s+forget\b",
    "restic forget removes snapshots and can permanently delete backup data.",
    suggestion: "Run 'restic snapshots' first to review what would be affected."
)

This approach ensures that suggestions are always relevant to the specific context, not generic warnings.

Simultaneously, the hook outputs JSON to stdout for the Claude Code protocol:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "BLOCKED by dcg\n\nReason: ..."
  }
}

Security Considerations

What This Protects Against

Accidental data loss: AI agents running git checkout -- or git reset --hard on files with uncommitted changes
Remote history destruction: Force pushes that overwrite shared branch history
Stash loss: Dropping or clearing stashes containing important work-in-progress
Filesystem accidents: Recursive deletion outside designated temp directories

Inherent Limitations

While dcg provides comprehensive protection across many tools and platforms, some attack vectors are inherently difficult or impossible to protect against:

Malicious actors: A determined attacker can bypass this hook
Non-Bash commands: Direct file writes via Python/JavaScript, API calls, etc. are not intercepted
Committed but unpushed work: The hook doesn’t prevent loss of local-only commits
Bugs in allowed commands: A git commit that accidentally includes wrong files
Commands in scripts: If an agent runs ./deploy.sh, we don’t inspect what’s inside the script

Threat Model

This hook assumes the AI agent is well-intentioned but fallible. It’s designed to catch honest mistakes, not adversarial attacks. The hook runs with the same permissions as the Claude Code process.

Troubleshooting

Hook not blocking commands

Check hook registration: Verify ~/.claude/settings.json contains the hook configuration
Restart Claude Code: Configuration changes require a restart
Check binary location: Ensure dcg is in your PATH
Test manually: Run echo '{"tool_name":"Bash","tool_input":{"command":"git reset --hard"}}' | dcg

Hook silently removed (recommended: add shell startup check)

Claude Code can silently remove the dcg hook when it rewrites ~/.claude/settings.json. This means you may lose protection without any warning.

Automatic setup – dcg setup installs the hook and offers to add a shell startup check:

1
2

dcg setup               # Interactive — prompts before modifying RC files
dcg setup --shell-check # Non-interactive — adds the check automatically

Manual setup – add this snippet to your ~/.zshrc and/or ~/.bashrc:

# dcg: warn if hook was silently removed from Claude Code settings
if command -v dcg &>/dev/null && command -v jq &>/dev/null; then
  if [ -f "$HOME/.claude/settings.json" ] && \
     ! jq -e '.hooks.PreToolUse[]? | select(.hooks[]?.command | test("dcg$"))' \
       "$HOME/.claude/settings.json" &>/dev/null; then
    printf '\033[1;33m[dcg] Hook missing from ~/.claude/settings.json — run: dcg install\033[0m\n'
  fi
fi

This check:

Runs in milliseconds (no noticeable shell startup delay)
Is completely silent when the hook is present
Shows a yellow warning only when the hook is missing
Gracefully skips if dcg, jq, or settings.json are absent
Works identically in bash and zsh

Note: The install.sh installer also offers to add this check during installation.

Hook blocking safe commands

Check for false positives: Some edge cases may not be covered by safe patterns
File an issue: Report the command that was incorrectly blocked
Temporary bypass: Have the user run the command manually in a separate terminal
Add to allowlist: Use the allowlist feature below for persistent overrides

Resolving False Positives with Allowlists

If dcg blocks a command that is safe in your specific context, you can add it to an allowlist. Allowlists support three layers (checked in order):

Project (.dcg/allowlist.toml): Applies only to the current project
User (~/.config/dcg/allowlist.toml): Applies to all your projects
System (/etc/dcg/allowlist.toml): Applies system-wide

Adding a rule to the allowlist:

# Allow a specific rule by ID (recommended)
dcg allowlist add core.git:reset-hard -r "Used for CI cleanup"

# Allow at project level (default if in a git repo)
dcg allowlist add core.git:reset-hard -r "CI cleanup" --project

# Add to user-level allowlist instead
dcg allowlist add core.git:reset-hard -r "Personal workflow" --user

# Allow with expiration (ISO 8601 format)
dcg allowlist add core.git:clean-force -r "Migration" --expires "2026-02-01T00:00:00Z"

# Allow a specific command (exact match) using add-command
dcg allowlist add-command "rm -rf ./build" -r "Build cleanup"

Listing allowlist entries:

# List all entries from all layers
dcg allowlist list

# List project allowlist only
dcg allowlist list --project

# List user allowlist only
dcg allowlist list --user

# Output as JSON
dcg allowlist list --format json

Removing entries:

# Remove a rule by ID
dcg allowlist remove core.git:reset-hard

# Remove from project allowlist specifically
dcg allowlist remove core.git:reset-hard --project

Validating allowlist files:

# Check for issues (expired entries, invalid patterns)
dcg allowlist validate

# Strict mode: treat warnings as errors
dcg allowlist validate --strict

Pruning expired entries:

# Preview expired entries without changing files
dcg allowlist prune --dry-run

# Remove expired entries from project/user allowlists
dcg allowlist prune

Example allowlist.toml:

[[allow]]
rule = "core.git:reset-hard"
reason = "Used for CI pipeline cleanup"
added_at = "2026-01-08T12:00:00Z"

[[allow]]
exact_command = "rm -rf ./build"
reason = "Safe build directory cleanup"
added_at = "2026-01-08T12:00:00Z"
expires_at = "2026-02-08T12:00:00Z"  # Optional expiration

[[allow]]
pattern = "rm -rf .*/build"
reason = "Build directories across projects"
risk_acknowledged = true  # Required for pattern-based entries
added_at = "2026-01-08T12:00:00Z"

Performance issues

Check pattern count: Excessive custom patterns can slow matching
Profile with --release: Debug builds are significantly slower
Check stdin buffering: Slow JSON input can delay processing

Running Tests

Unit Tests

`1`	`cargo test`

The test suite includes 80+ tests covering:

normalize_command_tests: Path stripping for git and rm binaries
quick_reject_tests: Fast-path filtering for non-git/rm commands
safe_pattern_tests: Whitelist accuracy for all safe pattern variants
destructive_pattern_tests: Blacklist coverage for all dangerous commands
input_parsing_tests: JSON parsing robustness and edge cases
deny_output_tests: Output format validation
integration_tests: End-to-end pipeline verification

Test with Coverage

1
2

cargo install cargo-tarpaulin
cargo tarpaulin --out Html

End-to-End Testing

The repository includes a comprehensive E2E test script with hundreds of command scenarios:

# Run full E2E test suite
./scripts/e2e_test.sh

# With verbose output
./scripts/e2e_test.sh --verbose

# With specific binary path
./scripts/e2e_test.sh --binary ./target/release/dcg

Codex CLI integration has a separate opt-in harness because it drives a real authenticated codex exec session against hermetic temporary repositories:

# Run the real Codex CLI smoke harness
./scripts/e2e_codex.sh --verbose --dcg-binary ./target/release/dcg

# Capture JSONL trace and failure artifacts for postmortems
./scripts/e2e_codex.sh --json --artifacts ./artifacts/codex-e2e --dcg-binary ./target/release/dcg

The Codex harness exits successfully with an explicit skipped status when Codex is unavailable or unauthenticated, so CI and developer machines without Codex access can run it without producing false failures. A full local run requires codex 0.125.0 or newer on PATH plus an authenticated codex login status; when Codex is responsive, expect roughly five minutes, with longer runtimes possible under rate limiting.

Useful debugging flags:

--verbose mirrors the per-scenario logging style from scripts/e2e_test.sh.
--artifacts DIR writes trace.jsonl plus per-failure stdout, stderr, prompts, repository state, manifests, and diffs.
--keep-tempdirs preserves temporary repositories and isolated Codex homes for manual inspection after a failed run.

CI runs ./scripts/e2e_codex.sh --verbose --json --artifacts /tmp/codex_e2e_artifacts in a dedicated codex-e2e job on pushes to main only. The job installs Codex with npm, authenticates from the CODEX_API_KEY secret, and still goes green with a clear notice when Codex is unavailable, unauthenticated, quota-limited, or temporarily unable to reach the API.

The E2E suite covers:

All destructive git commands (reset, checkout, restore, clean, push, branch, stash)
All safe git commands (status, log, diff, add, commit, push, branch -d)
Filesystem commands (rm -rf with various paths and flag orderings)
Absolute path handling (/usr/bin/git, /bin/rm)
Non-Bash tools (Read, Write, Edit, Grep, Glob)
Malformed JSON input (empty, missing fields, invalid syntax)
Edge cases (sudo prefixes, quoted paths, variable expansion)

Continuous Integration

The project uses GitHub Actions for CI/CD:

CI Workflow (`.github/workflows/ci.yml`)

Runs on every push and pull request:

Formatting check: cargo fmt --check
Clippy lints: cargo clippy --all-targets -- -D warnings (pedantic + nursery enabled)
Compilation check: cargo check --all-targets
Unit tests: cargo nextest run with JUnit XML reports
Coverage: cargo llvm-cov with LCOV output

Release Workflow (`.github/workflows/dist.yml`)

Triggered on version tags (v*):

Builds optimized binaries for 6 platforms:
- Linux x86_64 (x86_64-unknown-linux-gnu)
- Linux ARM64 (aarch64-unknown-linux-gnu)
- macOS Intel (x86_64-apple-darwin)
- macOS Apple Silicon (aarch64-apple-darwin)
- Windows x64 (x86_64-pc-windows-msvc)
- Windows ARM64 (aarch64-pc-windows-msvc)
Creates .tar.xz archives (Unix) or .zip (Windows)
Generates SHA256 checksums for verification
Publishes to GitHub Releases with auto-generated release notes

To create a release:

1
2

git tag v0.1.0
git push origin v0.1.0

FAQ

Q: Why block git branch -D but allow git branch -d?

The lowercase -d only deletes branches that have been fully merged. The uppercase -D force-deletes regardless of merge status, potentially losing commits that exist only on that branch.

Q: Why is git push --force-with-lease allowed?

Force-with-lease is a safer alternative that refuses to push if the remote has commits you haven’t seen. It prevents accidentally overwriting someone else’s work.

Q: Why block all rm -rf outside temp directories?

Recursive forced deletion is one of the most dangerous filesystem operations. Even with good intentions, a typo or wrong variable expansion can delete critical files. Temp directories are designed to be ephemeral.

Q: Can I add custom patterns?

Yes. Create YAML pack files and point to them in your config. See the Custom Packs section and docs/custom-packs.md for the schema and examples.

Q: What if I really need to run a blocked command?

See Escape Hatch / Bypass. Options include DCG_BYPASS=1, allow-once codes, permanent allowlists, or running the command manually in a separate terminal.

Q: Does this work with other AI coding tools?

Yes. dcg natively supports Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI, VS Code Copilot Chat, and Cursor IDE hook paths. Aider has limited git-hook support, and Continue is detected but cannot be auto-configured because it does not expose a pre-execution shell hook.

Q: What about database, Docker, Kubernetes, and cloud commands?

dcg includes 50+ packs covering all of these. See the Modular Pack System section for the full list. Enable the packs you need in your config.

Contributing

About Contributions: Please don’t take this the wrong way, but I do not accept outside contributions for any of my projects. I simply don’t have the mental bandwidth to review anything, and it’s my name on the thing, so I’m responsible for any problems it causes; thus, the risk-reward is highly asymmetric from my perspective. I’d also have to worry about other “stakeholders,” which seems unwise for tools I mostly make for myself for free. Feel free to submit issues, and even PRs if you want to illustrate a proposed fix, but know I won’t merge them directly. Instead, I’ll have Claude or Codex review submissions via gh and independently decide whether and how to address them. Bug reports in particular are welcome. Sorry if this offends, but I want to avoid wasted time and hurt feelings. I understand this isn’t in sync with the prevailing open-source ethos that seeks community contributions, but it’s the only way I can move at this velocity and keep my sanity.

License

MIT

Dcg on Producthunt daily

destructive_command_guard

Dicklesworthstone/destructive_command_guard

dcg (Destructive Command Guard)

Quick Install

Windows (native, PowerShell)

TL;DR

Why Use dcg?

Quick Example

Enable More Protection

Agent-Specific Profiles

Codex Support

Origins & Authors

Escape Hatch / Bypass

Modular Pack System

Enabled by default (no config file)

Storage Packs

Remote Packs

Database Packs

Container Packs

Kubernetes Packs

Cloud Provider Packs

CDN Packs

API Gateway Packs

Infrastructure Packs

System Packs

CI/CD Packs

Secrets Management Packs

Platform Packs

DNS Packs

Email Packs

Feature Flag Packs

Load Balancer Packs

Messaging Packs

Monitoring Packs

Payment Packs

Search Engine Packs

Backup Packs

Windows Packs

Other Packs

Custom Packs

Heredoc Three-Tier Architecture

Environment Variables

Output Formats and DCG_FORMAT

Configuration Hierarchy

Accessibility & Themes

Fail-Open Philosophy

Installation

Quick Install (Recommended)

From source (requires Rust nightly)

Manual build

Updating

Prebuilt Binaries

Uninstalling

Claude Code Configuration

Codex CLI Configuration

Gemini CLI Configuration

CLI Usage

Test Mode (dcg test)

Basic Usage

Exit Codes

Flags and Options

Output Formats

CI/CD Integration Examples

Troubleshooting

Explain Mode

Allow-Once (Temporary Exceptions)

Rebase Recovery Mode

Repository Scanning

What Scan Is (and Is Not)

Supported File Formats

Quick Start

Recommended Rollout Plan

Pre-Commit Integration

One-Command Install

Manual Setup

Uninstall

Interpreting Findings

Fixing Findings

Option 1: Change the Code (Preferred)

Output Formats and `DCG_FORMAT`

Test Mode (`dcg test`)

CI Workflow (`.github/workflows/ci.yml`)

Release Workflow (`.github/workflows/dist.yml`)