社会主义是科学和文化的社会。要成为社会主义社会的当之无愧的成员，应当努力地和好好地学习，获得很多的知识。——加里宁

https://github.com/Dicklesworthstone/destructive_command_guard

destructive_command_guard：给 AI 编码代理装上一道真正会拦人的护栏

AI 编码代理最大的魅力，在于它们敢动手。
但也正因为敢动手，一旦手滑，代价就可能非常直接：还没提交的改动被清空，目录被删，数据库被抹，云资源被误操作，辛辛苦苦堆出来的工作现场瞬间回到一片空白。

destructive_command_guard 想解决的，就是这种“不是不会写，而是太敢写、太敢执行”的风险。

根据仓库 description，Destructive Command Guard（dcg） 的目标，是阻止代理执行危险的 git 和 shell 命令。README 则把这个定位进一步讲清楚：它是一个高性能 hook，专门给 AI 编码代理使用，在危险命令真正执行前把它拦下来，避免工作成果被意外破坏。

项目地址：https://github.com/Dicklesworthstone/destructive_command_guard

它的出发点，非常现实，也非常痛

README 在 TL;DR 里把问题描述得很直接：

AI 编码代理有时会执行灾难性的命令，比如：

git reset --hard
rm -rf ./src
DROP TABLE users

而这些命令带来的后果也非常具体：摧毁数小时的未提交工作。

这并不是一个抽象的安全议题，也不只是“最好小心一点”的温和建议。它说的是一种很典型、而且越来越现实的开发事故：当 AI 具备操作终端和仓库的能力后，它不只是能帮你完成工作，也可能比人类更快地把错误执行到底。

dcg 的答案很明确：
在命令执行前拦截它。
不是事后恢复，不是出问题后安慰你，而是尽量在“危险还没发生”的那一瞬间把门关上。

它不是泛泛的提醒器，而是一个真正放在执行链路里的 hook

README 对 dcg 的定义不是“扫描器”而已，而是一个 hook for AI coding agents。

这意味着它不是在旁边做建议，也不是等命令跑完再总结风险，而是直接插在代理的命令执行流程中。
如果它判断命令具有破坏性，就会阻止执行，并给出原因和更安全的替代建议。

README 给了一个很有画面感的例子：

# 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.
════════════════════════════════════════════════════════════════

这段示例特别能体现 dcg 的气质：
不是冷冰冰地报一个错误码，而是把“为什么拦住你”“你刚才想干什么”“更稳妥的替代思路是什么”都说出来。它不像一把只会猛地拍下来的锤子，更像一个站在终端入口处、反应很快、脾气不坏、但底线很清楚的守门员。

README 列出的优势，几乎全都围绕“既要拦得住，也不能拖后腿”

dcg 的 Why Use dcg 一节做了非常密集的总结，里面有不少值得注意的点。

零配置保护

README 说，它开箱即用就能阻止危险的 git 和文件系统命令。

这意味着你不需要一开始就构建一套庞大策略，最关键的几个雷区一上来就有人盯着。

50+ Security Packs

它提供 50 多个安全包，覆盖数据库、Kubernetes、Docker、AWS/GCP/Azure、Terraform 等领域。

这说明 dcg 的视野并不只停留在 rm -rf 和 git reset --hard 这类经典终端事故，而是已经把“破坏性操作”扩展到了更广的工程环境里。

Sub-Millisecond Latency

README 强调它有 sub-millisecond latency，并且使用 SIMD-accelerated filtering。

这件事非常关键。因为一个 hook 如果每次都拖慢命令链路，哪怕再安全，用户也会很快失去耐心。dcg 明显很在意这一点：它想拦命令，但不想变成工作流的绊脚石。

Heredoc / Inline Script Scanning

它可以识别像下面这种嵌入式风险：

python -c "os.remove(...)"

以及嵌入在 shell 脚本中的危险内容。

这说明它并不满足于“只看表面命令词”，而是愿意进一步检查命令里包着的脚本内容。

Smart Context Detection

README 提到，它不会误伤像 grep "rm -rf" 这种数据内容，但会拦截真正执行的 rm -rf /。

这部分非常重要。
真正可用的保护，不是“什么都拦”，而是能区分文本和执行语义。否则工具很快就会陷入误报地狱。

Agent-Safe Streams

它会把机器可读的 hook 输出留在 stdout，而把更适合人看的富文本警告放在 stderr。

这说明 dcg 已经认真考虑了“人类终端体验”和“代理协议兼容性”之间的分工，而不是把所有信息混成一团。

Scan Mode for CI

它还支持用于预提交和 CI 的扫描模式，把危险命令检测从“运行时拦截”延伸到了“代码评审阶段发现”。

Fail-Open Design

README 明确写到：当超时或解析失败时，它默认不会因为自身问题把你的流程硬拦死。

这是一个很有态度的设计选择，后面它还专门展开解释。

pack 系统，是这个项目最有规模感的一部分

dcg 并不是靠几条硬编码规则在工作。README 说明，它采用了一个模块化的 pack system，用不同 pack 来组织不同类别的破坏性命令模式。

这会带来两层好处：

规则可以按类别组织，而不是混成一锅
用户可以按场景启用或禁用对应保护范围

例如 README 给出了这样一段配置：

# ~/.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
]

这种写法很直观。
你不需要去维护一堆零散正则，而是按“我需要保护哪个领域”来开启 pack。

默认保护并不贪心，但抓得很准

README 特别说明了：在没有配置文件时，dcg 默认只启用最能防止灾难性、不可恢复错误的几个 pack。

默认包括：

core.filesystem
core.git
system.disk

而在 Windows 上，还额外默认启用：

windows.filesystem
windows.system

这种默认策略其实很聪明。
它没有一上来就把所有领域的规则都压到用户头上，而是先把最危险、最容易造成无法挽回损失的那一层护住。

同时，README 也说得很清楚：像 database.postgresql、containers.docker 这类 pack 并不是“无配置默认启用”，而是需要你通过配置显式打开。项目在这点上非常明确，没有故意把“安装 starter config”混同于“默认行为”。

你能打开的保护范围，真的非常广

README 中的 pack 列表长得惊人，而且覆盖面很完整。它按类别组织了各种 destructive operation 保护，包括：

Storage Packs

storage.s3
storage.gcs
storage.minio
storage.azure_blob

Remote Packs

remote.rsync
remote.scp
remote.ssh

Database Packs

database.postgresql
database.mysql
database.mongodb
database.redis
database.sqlite
database.supabase

Container Packs

containers.docker
containers.compose
containers.podman

Kubernetes Packs

kubernetes.kubectl
kubernetes.helm
kubernetes.kustomize

Cloud Provider Packs

cloud.aws
cloud.azure
cloud.gcp

CDN、API Gateway、Infrastructure、CI/CD、Secrets、Platform、DNS、Email、Feature Flags、Load Balancer、Messaging、Monitoring、Payment、Search、Backup、Windows 等更多类别

单看这份清单，就已经能感受到 dcg 的范围不是“一个拦删库命令的小脚本”，而是一个试图系统化组织 destructive operation knowledge 的工程项目。

它还支持自定义 pack，这让它不只适合通用规则

README 说明，你可以用 YAML 自定义组织内部的 security packs，把内部工具、部署脚本和专有系统的风险规则也纳入 dcg。

配置方式如下：

[packs]
custom_paths = [
    "~/.config/dcg/packs/*.yaml",
    ".dcg/packs/*.yaml",
]

并且还提供了验证命令：

1	dcg pack validate mypack.yaml

这意味着 dcg 并不把自己限制为“作者维护的那份官方规则集”，而是承认现实世界里有大量组织私有环境，需要自己补充护栏。

heredoc 与 inline script 扫描，是它最技术味的一块

README 对 heredoc scanning 的描述相当详细，几乎像在读一份小型设计文档。

它提供了相关配置：

[heredoc]
enabled = true
timeout_ms = 50
max_body_bytes = 1048576
max_body_lines = 10000
max_heredocs = 10
fallback_on_parse_error = true
fallback_on_timeout = true

并说明支持 CLI 覆盖：

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

更有意思的是，README 把它的处理架构分成了三层：

Trigger Detection
Content Extraction
AST Pattern Matching

并给出了一个三层流水线示意。
这个设计很能体现 dcg 的目标平衡：既想识别深层脚本风险，又必须保证速度足够快，所以它不是一上来就做昂贵分析，而是先做极快触发筛选，再按需提取，再做 AST 级模式匹配。

README 甚至给出了 Rust 代码片段，展示 heredoc trigger 的正则集合，以及使用 AST 模式去识别如 subprocess.run 配合 shell=True 和 rm -rf 这类结构化风险。

这让人很清楚地看到：dcg 的“看得深”不是一句宣传词，而是已经有明确的处理分层。

它不仅拦命令，还尽量解释“为什么会拦”

README 提到一个很有用的功能：Explain Mode。

1	dcg explain "command"

它的作用是显示某条命令为什么会被拦。
这个功能的重要性不在于“酷”，而在于它能帮助你处理误报、理解规则，或者在 rollout 配置时做验证。

除此之外，README 也提供了 dcg test，用于在不执行命令的前提下评估它：

1	dcg test "rm -rf ./build"

如果需要机器可读输出：

1	dcg test --format json "kubectl delete namespace prod" \| jq -r .decision

这一组命令很像是在告诉用户：
你不需要拿真实生产命令去赌结果，先测、先解释、先验证，再决定怎么上规则。

它还认真考虑了 agent 差异，而不是把所有代理都当成同一种生物

README 有专门一节讲 Agent-Specific Profiles。

它说明 dcg 会自动检测是哪种 AI 编码代理在调用自己，并应用对应的 agent-specific configuration。支持的字段包括：

disabled_packs
extra_packs
additional_allowlist
disabled_allowlist

示例配置如下：

[agents.claude-code]
trust_level = "high"
additional_allowlist = ["npm run build", "cargo test"]
disabled_packs = ["kubernetes"]

[agents.unknown]
trust_level = "low"
extra_packs = ["paranoid"]
disabled_allowlist = true

README 还明确指出，trust_level 只是 advisory label，用于 JSON 输出和日志，不直接改变规则评估；真正行为差异来自其他字段。

这部分设计很讲究。它并不是简单给不同代理贴标签，而是允许你按代理特征调整规则、放行模式与 pack 组合。

Codex 支持被当成一等公民来处理

README 对 Codex CLI 的支持写得很完整，而且强调：
dcg 现在把 Codex CLI 当作 first-class hook target，而不是只走某种 Claude 兼容路径。

它说明安装器会在检测到 codex 或 ~/.codex/ 时自动配置 Codex CLI 0.125.0+。
同时，README 详细列出了 Codex 行为与 dcg 的对应处理方式，包括：

如何合并 PreToolUse Bash hook 到 ~/.codex/hooks.json
被拒绝命令如何返回最小 stdout denial
允许命令如何保持静默
如何保持已有 hooks 共存
如何从 turn_id 识别 Codex payload，并只输出 Codex 文档允许的 denial fields

这一段非常能说明 dcg 的协议意识：
它不是只会“我这边输出点东西”，而是知道不同代理对 hook 输出格式的接受范围不同，并且专门去适配。

支持的代理范围，也相当广

README 在开头就列出了支持范围，后面的安装说明则进一步展开 agent-specific notes。
它支持和涉及的环境包括：

Claude Code
Codex CLI 0.125.0+
Gemini CLI
GitHub Copilot CLI
Cursor IDE
Hermes Agent
Grok CLI
Antigravity CLI
Aider
Continue
VS Code Copilot Chat
以及一些未自动配置但可接入的环境

可以看出，dcg 想做的并不是某一个单独代理的伴生插件，而是一个横跨多种 AI 编码入口的保护层。

安装过程主打一个“尽量少折腾”

README 在 Quick Install 里给出了最核心的安装命令：

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

Windows PowerShell 则使用：

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

README 说明 easy mode 会自动：

检测平台
下载对应二进制
配置所有支持的 AI agent hooks
在合适时校验 SHA256
有条件时校验 Sigstore/cosign

此外还支持：

交互安装
指定版本安装
系统级安装
从源码安装
仅下载不配置 hook

例如：

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

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

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

这种安装设计很符合它的定位：既然是保护层，就得尽可能早地、轻松地装上。

从源码构建也写得很清楚

README 说明，该项目使用 Rust Edition 2024 特性，因此需要 nightly toolchain。仓库提供了 rust-toolchain.toml 用于自动选择工具链。

直接从 GitHub 安装可以这样做：

1 2	rustup install nightly cargo +nightly install --git https://github.com/Dicklesworthstone/destructive_command_guard destructive_command_guard

手动构建方式则是：

git clone https://github.com/Dicklesworthstone/destructive_command_guard
cd destructive_command_guard
cargo build --release
cp target/release/dcg ~/.local/bin/

仓库 metadata 也显示，这个项目的主要语言是 Rust。这和 README 中反复强调的性能目标、低延迟和结构化处理思路非常一致。

CI 与代码审查场景也没有被漏掉

dcg 不只是一个本地 hook。仓库里的 action/README.md 说明，它还提供了一个 GitHub Action，用于扫描仓库中处于可执行上下文里的 destructive commands，例如：

shell scripts
Dockerfiles
GitHub Actions workflows
GitLab CI configs
Makefiles
package.json scripts
Docker Compose files
Terraform provisioners

最简单的 workflow 示例是：

name: Security Scan
on: [push, pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: Dicklesworthstone/destructive_command_guard/action@v0
        with:
          fail-on: error

README 还给了 PR diff 扫描、全仓扫描、指定目录扫描，以及在后续步骤消费结果的示例。
这说明 dcg 的思路不是只在运行瞬间拦截，也包括在代码评审与持续集成阶段提早发现风险。

“逃生舱”设计得很克制，但很必要

一个只会硬拦、完全不给出口的保护工具，通常很快会逼用户把它彻底关掉。dcg 显然知道这一点，所以 README 里专门提供了 Escape Hatch / Bypass。

几种方式包括：

DCG_BYPASS=1 <command>
dcg allow-once <code>
dcg allowlist add ...
直接移除 hook

README 也明确提醒：DCG_BYPASS=1 会彻底关闭这次调用的所有保护，应谨慎使用，并更推荐对常见需求采用 allowlist。

这种设计很像一个成熟的安全工具应有的样子：
拦得住危险，但也承认真实世界里总会有必须越过护栏的时候，因此出口要有，但要让人意识到自己正在越界。

它的配置体系非常完整，而且层级关系说得很透

README 中给出了配置优先级：

环境变量
显式配置文件
项目级 .dcg.toml
用户级 ~/.config/dcg/config.toml
系统级 /etc/dcg/config.toml
编译默认值

同时也给了配置文件位置表、合并行为解释，甚至用 Rust 代码片段说明“只覆盖显式设置字段，其余字段继承低优先级层”。

这类描述特别能打动工程用户，因为它说明项目不是把配置当成“有了就行”，而是认真考虑了组织默认值、个人偏好和项目特定需求如何共存。

README 甚至支持按项目路径配置不同 packs：

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

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

这让 dcg 可以在“严肃生产仓库”和“个人实验仓库”之间体现不同警觉程度。

fail-open 哲学，是这个项目最值得注意的设计立场之一

README 用了专门一节讲 Fail-Open Philosophy。

它的核心意思是：
当 dcg 因为超时、解析错误或资源限制，无法安全分析命令 时，默认会允许命令继续，而不是因为自身不确定就卡死你的流程。

README 给出的理由包括：

工作流连续性
性能保证
优雅降级

并列举了多种 fail-open 场景，例如：

heredoc 解析错误
提取超时
size limit exceeded
regex engine timeout
AST matching error
deadline exceeded

同时，它也提供了更严格的配置方式。
例如 heredoc 部分可以关闭 parse error / timeout fallback，而顶层 hook 输入还可以通过：

1 2	[general] fail_closed = true

或者：

1	DCG_FAIL_CLOSED=1

切换到 fail-closed 模式。

这部分读下来，会觉得 dcg 很明白自己所处的位置：
它是保护层，但不是统治者。默认情况下，它宁可在自己看不清时不挡路，也不想因为自身分析失败把用户逼疯；而在高安全场景下，它又允许你主动把规则收紧。

还有一些很“工程师”的细节，藏得很妙

README 里还有不少一看就知道不是随手写上的细节，例如：

绝对超时上限是 200ms
支持 DCG_FORMAT
非 dcg scan 命令上的 sarif 会作为 JSON 别名平滑降级
支持高对比度与色弱友好配色
颜色不会单独承载语义，始终配合符号和标签
支持 DCG_ROBOT=1
支持 DCG_NO_RICH=1
支持 DCG_HIGH_CONTRAST=1

这些细节汇总起来，会让人觉得这个项目并不是“先有一个想法，再拼点规则”，而是经过了很多实际终端环境、自动化场景和可访问性考虑之后慢慢打磨出来的。

仓库里还顺手放着一个 AI-native issue tracking 入口

仓库中的 .beads/README.md 说明，这个项目使用 Beads 做 issue tracking。README 描述 Beads 是一个 living in repo 的、面向 AI coding agents 的 issue tracking 工具，强调 CLI-first、Git-native、branch-aware。

虽然这不是 dcg 的核心功能，但它至少说明一个小事实：这个仓库本身也在尝试采用更贴近 AI-assisted development 的工作方式。

从仓库信息看，它的身份很清楚

根据仓库 metadata：

仓库名是 Dicklesworthstone/destructive_command_guard
默认分支是 main
主要语言是 Rust
description 明确写它是用来阻止代理执行危险 git 和 shell 命令的
仓库创建于 2026 年 1 月 7 日

配合 README 的体量和细致程度，这个项目给人的感觉很鲜明：
它不是泛泛而谈“AI 安全”，而是专门盯着一个足够危险、足够具体、足够频繁发生的问题去做工程化防护。

如果把 dcg 拟人化，它像一个不爱大喊大叫的保安

它不会在你每次开门时都盘问半天，也不会因为看见一个类似危险词就乱按警报。大部分时候，它低调得几乎像不存在；但一旦看见代理正准备扛着锤子冲进仓库，它会立刻站出来，把锤子先按住，再告诉你：这一下真砸下去，后果可不轻。

而且它还不只是会说“不行”。它会说：为什么不行，危险在哪里，能不能换条路走，或者你是否真的有必要临时开一次口子。

结语

destructive_command_guard 的价值，不在于它把“危险命令检测”这个概念喊得多响，而在于它把这件事做成了一套真正能落到 AI 代理执行链路里的保护机制。README 展示出来的，不只是几个阻止 rm -rf 的规则，而是一整套围绕 hook 集成、pack 系统、脚本深度扫描、agent 差异适配、CI 扫描、配置层级、逃生舱和 fail-open 哲学构建起来的安全护栏。

在 AI 编码代理越来越像“会直接动手的搭档”的今天，dcg 做的事情非常朴素，也非常必要：
在出事之前，先把最危险的那一步拦下来。