文档大纲

AI Coding Agent误删代码：destructive_command_guard给你装了一个后悔药

如果你正在用 Claude Code、Codex CLI、Cursor 这些 AI Coding Agent，你大概率担心过一件事——它真的删错了东西怎么办？Dicklesworthstone/destructive_command_guard（dcg）这个 4.8k 星的 Rust Hook 把这个担忧变成了一行安装命令。这篇能带走的：

① 你是不是真的需要这个工具（什么时候它救你，什么时候它多余）

② 它怎么用 SIMD 把延迟压到子毫秒级

③ 50+ 安全 Pack 怎么覆盖数据库、K8s、云厂商、Docker

④ 怎么配 Claude Code / Cursor / Codex 等不同 Agent 的差异化策略。

如果你正在用 Claude Code、Codex CLI、Cursor 这些 AI Coding Agent，你大概率担心过一件事：它真的删错了东西怎么办？一个 GitHub 4.8k 星的项目，把这个担忧变成了一行安装命令。

上周五晚上 11 点，我在 Claude Code 里让它"清理几个调试用的临时文件"。它很贴心地帮我执行了 rm -rf——可惜，-rf 的范围远不止"几个临时文件"。等我反应过来，几百行未提交的代码已经没了。

这不是段子，而是 Dicklesworthstone/destructive_command_guard（简称 dcg）的作者想要解决的核心问题：AI Coding Agent 破坏力强，但判断力有限。这个用 Rust 写的 Hook 在破坏性命令真正执行前拦住它们，并告诉你为什么拦、建议怎么做。

这篇能带走的：① 你是不是真的需要这个工具（什么时候它救你，什么时候它多余）② 它怎么用 SIMD 把延迟压到子毫秒级 ③ 50+ 安全 Pack 怎么覆盖数据库、K8s、云厂商、Docker ④ 怎么配 Claude Code / Cursor / Codex 等不同 Agent 的差异化策略。

项目基本信息

项目数据

字段值
全名Dicklesworthstone/destructivecommandguard（dcg）
星标4,835（今日 +471）
语言Rust
许可证Custom
最近更新2026-07-15

话题标签

ai-agents, cli, developer-tools, git, rust, safety

核心问题

AI 编码 Agent（Claude Code、Codex CLI、Gemini CLI 等）会执行破坏性命令，导致未提交的代码在几秒内被删除。

核心功能

一句话描述

一个高性能的 Rust Hook，在破坏性命令执行前进行拦截，保护 AI 编码 Agent 的工作不被意外销毁。

工作原理

它不是一个 IDE 插件，也不是一个 LLM 层的"安全 Agent"。它的做法很朴素：做一个命令级别的预检层。当 Claude Code 之类的 Agent 想要执行任何 shell 命令时，dcg 先拦下来问一句"这个命令你想清楚了吗？"——如果是 rm -rf、git reset --hard、DROP DATABASE 这种高度危险的命令，dcg 默认就把它挡掉。

技术架构

三层架构

  • 规则引擎：SIMD 加速的正则表达式匹配，子毫秒级延迟
  • 模块化 Pack 系统：50+ 安全 Pack，按类别组织（数据库、K8s、Docker、云厂商等）
  • Agent 检测器：自动识别调用方是哪种 Agent，应用对应策略

什么是 SIMD

SIMD（Single Instruction Multiple Data）是 CPU 的一种并行指令集，简单说就是"一次处理多个数据"。dcg 用它来加速正则匹配——你可能觉得一条命令的匹配怎么会慢？但当 Agent 一次粘贴 50 行 shell 脚本时，每一行都要匹配几十条规则，没有 SIMD 就会被卡住。

默认启用的核心 Pack

Pack保护内容
core.filesystem危险的 rm -rf（仅限临时目录外）
core.git销毁未提交工作的 Git 命令
system.diskmkfs、dd 到设备、分区表修改

即使你完全没读过配置文档、没建过配置文件，dcg 装上之后也会自动启用这三个 Pack——覆盖 90% 的"我手滑了"场景。

支持的 AI Agent 列表

Claude Code、Codex CLI 0.125.0+、Gemini CLI、GitHub Copilot CLI、VS Code Copilot Chat、Cursor IDE、Hermes Agent、Grok (xAI)、Antigravity CLI (agy)、OpenCode、Pi、Aider（仅 git hooks）、Continue（仅检测）。

注意 Aider 和 Continue 只支持部分检测：前者仅在 git hooks 层生效（不会主动拦截 Agent 内的命令），后者仅检测、不拦截。这种差异化设计是有意为之——不同 Agent 的"信任级别"和"工作模式"不一样，不能用同一套规则硬套。

安全 Pack 分类（部分）

数据库类

  • database.postgresql — DROP DATABASE, TRUNCATE, dropdb
  • database.mysql / database.mongodb / database.redis / database.sqlite
  • database.supabase — Supabase CLI 全部危险操作

云厂商类

  • cloud.aws — terminate-instances, delete-db-instance, s3 rm –recursive
  • cloud.azure / cloud.gcp — 对应云厂商危险操作

K8s / Docker 类

  • kubernetes.kubectl — delete namespace, drain, mass deletion
  • containers.docker — system prune, volume prune

CDN / API Gateway

  • cdn.cloudflare_workers — Workers/KV/R2/D1 危险操作
  • apigateway.aws / apigateway.kong

CI/CD

  • cicd.github_actions — 删除 secrets/variables
  • cicd.gitlab_ci — 删除 variables、artifacts、runners

其他类别

此外还有 Secrets / DNS / Email 等共计 50+ Pack。如果你只用 Claude Code 写写代码、不碰云资源，前 10 个 Pack 就够用了；如果你是 DevOps 或者负责生产环境，建议至少打开 cloud.aws、kubernetes.kubectl、cicd.github_actions 这三个。

安装方式

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

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

–easy-mode 是给新手的开关：装完后自动启用核心 Pack，不写任何配置也能用。如果你想完全掌控，删掉这个参数走手动模式。

使用示例

# AI Agent 尝试执行：
$ git reset --hard HEAD~5

# dcg 拦截并阻止：
════════════════════════════════════════════════════════════════
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.
════════════════════════════════════════════════════════════════

输出格式

注意 Reason 和 Tip——这不是简单的"拦截"消息，而是告诉 Agent 为什么拦和建议怎么做。这一点很关键：大多数 Agent 看到 BLOCKED 后会理解意图，自动改用 git stash 重新尝试。这就把"AI 做错事 → 人工救火"变成了"AI 做错事 → AI 自动修正"。

为什么 Agent 不会卡死

很多 AI Agent 看到 "BLOCKED" 就停了——它们不知道怎么往下走。dcg 的设计聪明在：它不仅说"不行"，还说"用 X 替代"。Agent 收到这个 Tip 后能自动重试，整个流程不需要人工介入。

配置文件示例

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

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

[agents.unknown]
trust_level = "low"
extra_packs = ["strict_git", "database"]
disabled_allowlist = true

trust_level 的妙用

这里有个非常聪明的设计：trust_level。如果你确认 Agent 是 Claude Code（你登录了、你能看到它的进程），就给 high 信任、放宽一些限制；如果 Agent 是 unknown（比如某个跑在容器里的脚本调 Claude API），就给 low 信任、启用更多 Pack。这种"差异化信任"的思路，比传统"是用户就全开，不是用户就全关"的二元判断要灵活得多。

allowed/disallowed 双向控制

additional_allowlist 是允许的补充命令列表，disabled_packs 是要禁用的 Pack 名列表——前者是"信任 Agent 可以做什么"，后者是"不信任 Agent 不可以做什么"。两者结合使用，可以为每个 Agent 画出精确的权限边界。

核心特性总结

特性说明
零配置保护默认阻止最灾难性的命令
50+ 安全 Pack覆盖数据库/K8s/云厂商/CI
子毫秒延迟SIMD 加速过滤
Heredoc/内联脚本扫描捕获 python -c "os.remove(…)"
智能上下文检测grep "rm -rf" 不会被阻止
丰富的终端输出人类可读的拒绝面板
Agent-Safe 流机器可读输出在 stdout，人类界面在 stderr
Fail-Open 设计永远不会因超时阻塞工作流

最后一行 Fail-Open 是个产品哲学：即使 dcg 自己崩溃了，也不会阻塞你的工作流。这避免了"为了安全把生产力搞没了"的问题——很多安全工具栽在这上面。

对所有 AI Coding Agent 使用者的启示

核心痛点：缺乏原生拦截机制

dcg 解决的是 AI Coding Agent 执行破坏性命令的核心痛点。无论你用 Claude Code、Cursor、Codex CLI 还是国内的各种 AI IDE，目前大多数 AI Coding Agent 都缺乏原生的破坏性命令拦截机制。

三个落地建议

  • 参考 dcg 的 Pack 系统，为你常用的 Agent 设计一个 dangerous_command_guard
  • 针对 exec 工具调用，增加命令白名单/黑名单预检
  • 特别是在生产环境执行时，对 rm、git reset –hard、DROP 等命令进行拦截提示

什么时候需要它

如果你只是在自己电脑上写写 demo 代码、跑跑测试用例，这个工具可能对你多余。但只要你的项目有真实用户、有生产数据库、有云资源——哪怕只是个人项目，rm -rf 误删一次就能让你后悔一整年。

技术实现参考

SIMD 加速正则

dcg 使用 SIMD 加速的正则匹配，性能优异。如果你要在自己的 Agent 里实现命令过滤，可以参考其 lazy-compiled regex 模式——不要在每次匹配时重新编译规则集，把正则编译结果缓存起来。

模块化 Pack 设计

按领域划分安全规则，便于扩展和维护——不要把所有规则堆在一个文件里。dcg 把 50+ Pack 分成数据库、K8s、云厂商、CI/CD 等大类，每类一个独立模块，新增规则时不会影响其他模块。

Agent 检测 + 差异化策略

不同 Agent 有不同信任级别，应用不同规则。trust_level 是关键参数——同一个 npm run build 命令，high 信任 Agent 跑没事，low 信任 Agent 跑就要复审。

产品思路

Fail-Open vs Fail-Close

dcg 默认 Fail-Open（不阻止工作流），但支持配置为 Fail-Close。建议本地开发用 Fail-Open 保持流畅，生产环境用 Fail-Close 严格保护。

Escape Hatch 设计

提供绕过机制（DCG_BYPASS=1），避免绝对拦截影响正常操作——比如紧急修复线上事故时，你需要能强制执行。但 Escape Hatch 不能做成"一键全放行"，要保留审计日志。

拦截消息要带建议

dcg 的拦截输出不只说"不行"，还说"你可以用 git stash"。这对 Agent 特别重要：Agent 看到"不行"会卡住；看到"用 X 替代"会自动修复。这是 prompt 和工具的差异化设计。

通用安全建议

主要误操作场景

dcg 的成功在于它解决了"AI Agent 破坏力强但判断力有限"的问题。同样的问题也存在于：

  • 数据库操作（DROP TABLE、DELETE 无 WHERE 条件）
  • 文件系统操作（rm -rf）
  • 云资源操作（删除实例、存储桶）

自动备份机制

建议任何在用 AI Coding Agent 的人在执行这些操作前，都增加一个确认步骤或自动备份机制。最简单的方案：把数据库每天自动备份到 OSS（阿里云/腾讯云对象存储），把代码 push 到远程 Git——这两个动作加起来的成本不超过 10 分钟一次，能挡住 90% 的"AI 误操作"事故。

写在最后：什么时候你需要它 / 什么时候你用不上它

你需要 dcg 的场景

  • 你的项目接入了真实数据库/云资源
  • 你经常让 Agent 执行 shell 命令而不只是生成代码片段
  • 你所在团队有协作成员会共享 Agent 环境
  • 你经历过哪怕一次 Agent 误操作
  • 你的生产环境对可用性敏感

你暂时用不上 dcg 的场景

  • 你只用 Agent 生成代码片段，shell 命令自己手动跑
  • 你在沙箱/Docker 里开发，误操作影响范围有限
  • 你正在调研 Agent 还没真用上
  • 你的代码全部 commit 在 Git，Agent 误删也能秒级恢复

总结

dcg 不是万能药——它拦不住 Agent 在 Python 层面犯的逻辑错误（比如帮你写了个 bug 让你生产事故），它只拦"破坏性命令"这一类。但仅这一类，已经能挡住大部分"我会哭出声"的损失。

阅读量： 338

网站备案号：沪ICP备2025137870号