首页 / 开源热榜 / destructive_command_guard / 使用教程

Destructive Command Guard 0.14.4:给 Codex 增加一层命令检查

更新于 2026-09-23 · NGJOO AI 实验室 · 约 11 分钟

Destructive Command Guard,简称 dcg,是一个 Rust hook。编码代理准备执行 shell 命令时,它先检查命令是否会递归删除文件、改写 Git 历史、破坏数据库或基础设施,再返回允许、询问或拒绝。

v0.14.4 发布于 2026-09-16,集中修复了把普通文件名、--、变量和内联载荷误判为危险操作的问题。Codex 集成要求 CLI 0.125.0 或更高。

1. 默认保护范围没有想象中大

项目有 50 多个安全包,但在没有配置文件时只启用三组:core.filesystemcore.gitsystem.disk。数据库、Docker、Kubernetes、云平台和 Terraform 等规则需要配置或安装器生成的 starter config 才会启用。

core.* 总会参与检查,不过策略仍能针对单条规则放宽。critical 规则不会被宽泛的 pack 级 warn/log 直接降级;真要放宽,必须写明确的 per-rule 条目。安装后应使用 dcg explain --format json 看最终结果,不能只看配置文件。

2. macOS 安装和 Codex hook

Homebrew 路径把下载二进制与修改 hook 分开:

brew install dicklesworthstone/tap/dcg
dcg install

第一条只安装 dcg,第二条才检测代理并写入 hook。对 Codex,它会合并 PreToolUse Bash hook,并保留已有 hook;如果现有 JSON 损坏,安装器会拒绝覆盖。hook 应保存 dcg 的绝对路径,因为代理进程的 PATH 可能与终端不同。

官方也提供 curl 与 PowerShell 安装器,要求 SHA256 校验,并在工具可用时检查 minisign 或 Sigstore/cosign。管道执行远程脚本前,先阅读脚本、固定版本,并在隔离环境完成测试。

3. 先测允许和拒绝两条路径

不要在重要仓库里用真正的删除命令测试。建立可丢弃目录,先确认普通读取或状态命令能通过,再用官方文档中的测试方法提交一个不会实际落地但应被识别的危险形状。查看代理 UI 是否明确显示“被 hook 拒绝”,并检查 stderr 或审计记录。

dcg 还会扫描 heredoc,以及 python -cbash -c 等内联载荷。dcg scan 可检查仓库中可执行上下文并输出 SARIF;它不是任意语言的完整静态分析器,也不能替代代码审查。

4. fail-open 和无人值守配置

官方失败策略明确说明:畸形或过大的原始 hook JSON 默认允许执行,同时写审计警告。希望无法解析时直接拒绝,可配置:

[general]
fail_closed = true
unverified_decision = "deny"

unverified_decision="deny"处理的是超过命令长度或检查超时等“无法验证”结果。默认 ask 依赖现场有人确认;无人值守任务不应假定这个问题会被安全回答。短暂 stdin I/O 错误即使开启 fail-closed 仍会放行,这是官方保留的边界。

5. 绕过、许可与商业化判断

DCG_BYPASS=1 会关闭该次命令的全部 dcg 保护;allow-once、永久 allowlist 和移除 hook 也能放行。它是一层可配置护栏,不是不可绕过的权限系统。

LICENSE以 MIT 文本为基础,但附加 OpenAI/Anthropic Rider,限制指定主体使用、分发和衍生。它不能简单标作标准 MIT。

验证边界:本轮只核对官方 README、LICENSE、Codex 集成说明和 v0.14.4 release。没有下载安装 dcg,没有修改本机 hook,也没有执行阻断、scan、explain、绕过或 fail-closed 测试;本文属于 docs-only 核对。

6. 与 Codex sandbox 对比

Codex sandbox 与 approval控制进程可以访问哪些文件、网络和系统资源,以及何时需要人工批准。dcg 在命令送去执行前匹配具体危险模式,还能为多种编码代理共享规则。

两者覆盖不同层次。沙箱负责权限边界,dcg 识别命令形状;可靠做法是同时保留最小权限、审批策略、Git 提交和备份。

这里仅补原教程没有展开的事实和边界。安装命令与操作步骤仍以前文为准。

先判断这个项目是否适合你

适合谁用

适合给 Codex、Claude Code、Gemini CLI 等代理增加命令级第二道检查,尤其是含未提交修改或可访问生产工具的环境。无人值守任务应把 unverified_decision 设为 deny,并评估 general.fail_closed;同时保留 Git 提交、备份、最小权限和代理自身沙箱。

采用建议

dcg 可以补上编码代理的命令模式检查,但安装完成不等于保护完成。上线前必须核对 hook 绝对路径、实际启用的 pack、fail-open 与 unverified 策略,并在隔离环境验证允许和拒绝两条路径。

原教程未展开的系统信息

核心功能

  • 命令执行前 hook

    dcg 接收代理 hook 的命令数据,分类真实执行上下文,再返回允许、询问或拒绝结果;Codex CLI 0.125.0+ 有专门输出格式。

架构与数据流

dcg 由 agent hook 接收 JSON,先辨认宿主与命令字段,再用快速过滤、上下文分类和规则引擎检查外层命令及 heredoc/inline payload。规则按 pack 分组,策略层把命中转换为 deny、warn、ask 或 log。它只看准备执行的命令文本与上下文,不理解整个程序的业务语义。

常见问题

安装 dcg 后,代理还能执行破坏性命令吗?

仍有可能。它可被 bypass、allow-once、allowlist 或删除 hook 绕过,也可能存在未覆盖模式或配置错误。

为什么 hook 里要写 dcg 的绝对路径?

代理 hook 的 PATH 可能与终端不同。绝对路径可避免找不到二进制后保护失效。

dcg 默认会对无法解析的 hook 输入拒绝执行吗?

不会。原始 hook JSON 无法解析时默认 fail-open;可显式启用 general.fail_closed=true

dcg 是标准 MIT 许可证吗?

不是。其许可标题和正文包含 OpenAI/Anthropic Rider,采用前需要阅读完整限制。