这类工具先看两个问题：危险命令有没有经过它，工具出错时会不会放行。Destructive Command Guard在第一点存在hook覆盖缺口，在第二点默认fail-open。所以它能拦下一部分危险命令，但不能当成安全沙箱。

核心判断：安全价值来自“执行前、可解释、可配置”，安全边界则取决于命令是否真的进入hook、故障时选择放行还是阻断，以及谁能修改例外配置。

环节项目机制主要价值关键边界 命令进入Agent hook协议在执行前获得命令未进入hook就看不到默认规则Git、文件系统、磁盘覆盖常见破坏动作数据库等规则需显式启用返回拒绝协议化deny回执阻止并解释缘由文档仍有协议冲突例外处理allow-once、allowlist、bypass处理明确安全操作配置失控会扩大放行面故障策略默认fail-open避免工具故障阻断工作安全上会保留放行路径

AI编程Agent的能力已经不只停在生成代码。它会读取项目、修改文件、运行测试，也可能执行Git、文件系统和系统命令。此时，错误答案最多需要重新修改；错误命令则可能直接改变工作区、历史记录或本地数据。

Destructive Command Guard的位置，是Agent决定调用shell之后、命令真正执行之前。它读取hook提供的命令文本，再使用规则包检查危险模式。项目默认核心保护覆盖Git、文件系统和磁盘类命令，也支持外部YAML规则包。

数据库、云平台和容器规则默认不开。装好后直接测试删库命令，可能根本不会被拦。

二、拒绝命令为什么也要遵守协议

规则命中后，工具不能只打印一句警告然后退出。上游Agent需要收到结构正确的拒绝回执，才能把这次调用理解为“被安全策略拒绝”，而不是普通工具崩溃。

Codex集成文档和配置文档对拒绝协议的写法不一致。我会以实现和协议测试为准：stdout输出最小JSON，stderr写人类可读缘由，exit code使用0。否则，上游可能把拒绝当成hook故障，再按fail-open继续执行。

三、allow-once不是默认只用一次

任何规则型护栏都会遇到误报。项目提供了几类出口：临时例外、持久allowlist，以及通过DCG_BYPASS=1对单次调用关闭全部保护。

最容易写错的是allow-once。官方README说明，默认例外最长保留24小时，并且绑定具体命令和目录范围。只有加上–single-use时，它才会在首次使用后失效。

这比“只授权当前动作”更复杂，也更接近真实开发：它能避免同一个已核查命令反复弹警告，但同时要求团队控制谁能创建例外、谁能改白名单、谁能设置bypass。

四、fail-open与hook覆盖缺口

项目默认采用fail-open。解析错误、超时或资源限制发生时，命令一般继续执行。可以通过配置收紧为fail-closed，但文档仍指出，顶层瞬时IO错误可能保持fail-open。

这是一种可用性与安全性的取舍。默认放行能避免护栏故障让所有开发工作停摆，却不能被包装成绝对阻断。

覆盖缺口更直接。Windows文档说明，部分Codex Desktop或codex exec路径可能使用unified_exec，而当前PreToolUse hook不能拦截全部此类调用。命令没有进入DCG，就不存在匹配、拒绝或日志。

五、版本和许可证也要提前说明

截至2026-07-13，正式GitHub Release最新为v0.6.5。main分支CHANGELOG已有v0.6.6条目并标成Release，但保存的GitHub Releases和tags API快照没有v0.6.6，Cargo.toml仍为0.6.5。因此更准确的说法是：仓库元数据存在冲突，不能把v0.6.6写成正式发布。

许可证也不是普通一句“MIT”能带过。Cargo manifest写MIT，但LICENSE标题包含OpenAI/Anthropic Rider，GitHub API返回NOASSERTION。这个项目源码公开，但许可证含非标准限制；采用前需要直接审阅LICENSE，尤其是与Codex、Claude Code相关的使用场景。

我的使用顺序会是：先做最小权限和环境隔离，再配版本控制、远端备份和审计日志，最后才加DCG。它补的是执行前检查，不负责兜底整套安全。