AI 编程 Agent 可以运行 Shell 后，最大的风险之一不是代码写错，而是在错误目录执行删除、覆盖或 Git 清理命令。Destructive Command Guard，简称 dcg，会作为工具调用前置 Hook 检查命令，在执行前拦截高风险操作。
项目地址：Dicklesworthstone/destructive_command_guard
快速答案
dcg 支持 Codex CLI、Claude Code、Gemini CLI、Copilot CLI、Cursor 等工具。它适合作为额外防线，但不是完整沙箱：Agent 仍可能把危险操作写进脚本，部分执行路径也可能绕过 Hook。
Linux、macOS 和 WSL 的快速安装：
|
|
远程安装脚本应先审查。安装器会下载对应平台二进制、校验哈希，并合并支持的 Agent Hook 配置，而不是直接覆盖合法的现有 JSON。
Codex 中怎样工作
对支持 Hooks 的 Codex CLI，安装器会向 ~/.codex/hooks.json 合并 PreToolUse Hook。安装完成后打开一次 Codex 的 /hooks 界面确认信任。
当 Agent 准备执行命令时，dcg 会：
- 解析工具调用的 JSON；
- 提取并规范化 Shell 命令；
- 快速排除明显安全的命令；
- 用规则识别删除、覆盖、强制重置等风险；
- 返回允许、拒绝或需要人工确认。
给仓库增加预提交扫描
除了实时 Hook，还可以扫描将要提交的脚本和工作流：
|
|
团队导入时建议先采用“高严重度才失败”的保守策略，观察误报后再扩大到 Makefile、Dockerfile 和更多 Shell 脚本。
安装后如何验证
不要用真实删除命令测试。可以让 Agent 解释一条明显危险的模拟命令，并观察 Hook 是否在执行前给出阻止信息。随后检查：
dcg是否位于PATH；- Agent 的 Hook 配置是否为有效 JSON；
/hooks是否显示并信任该 Hook；- 原有 Hook 是否仍然存在；
- 普通只读命令是否没有明显延迟。
安装方式与平台差异
Linux、macOS 和 WSL 可以使用 Shell 安装器。原生 Windows 应使用仓库提供的 install.ps1，不要在 PowerShell 中硬套 Bash 命令。
安装前建议：
- 打开脚本检查下载地址；
- 备份 Agent 的 Hook 配置；
- 记录现有
PATH； - 确认安装版本和校验机制；
- 在测试账户或测试环境先运行；
- 安装后查看配置差异。
Easy Mode 会尝试自动检测并配置支持的 Agent。团队环境更适合先使用 --no-configure 只安装二进制，再人工审核各工具的 Hook 合并。
Codex Hook 的完整检查
新版 Codex CLI 使用 ~/.codex/hooks.json 中的 PreToolUse Hook。配置完成后：
- 确认 JSON 能正常解析；
- 检查原有 Hooks 没有被删除；
- 在 Codex 中打开
/hooks； - 明确信任 dcg Hook；
- 用无破坏性的模拟请求测试阻止流程；
- 查看普通命令是否仍可通过。
如果 /hooks 没有显示，不要假设保护已经生效。检查 Codex 版本、功能支持和实际配置路径。
哪些命令容易被拦截
dcg 关注可能造成不可恢复损失的 Git 和 Shell 操作，例如递归删除、强制清理、覆盖历史和针对宽泛目录的危险命令。实际规则会更新，应以当前版本为准。
一个命令是否危险，不只看命令名，还要看参数和目标：
|
|
不要为了绕过误报把命令拆成多个更隐蔽步骤。应修正规则、使用明确目标或交给人工执行。
Scan 模式怎样用于代码库
实时 Hook 保护 Agent 当前准备执行的命令，dcg scan 则检查仓库中可能执行的 Shell 片段，包括脚本、CI 工作流、Dockerfile 和 Makefile。
首次导入建议：
|
|
只让高置信度严重问题阻止提交。观察一段时间后，再把范围扩大到：
|
|
不要第一天就把所有 Warning 设为 CI 失败，否则误报会促使团队直接关闭工具。
预提交 Hook 与 CI 的职责
本地预提交
反馈快，适合在提交前发现新增危险命令，但用户可用 --no-verify 绕过，也可能没有安装 Hook。
CI 扫描
由仓库统一执行，更适合形成强制规则。CI 中应固定 dcg 版本、验证下载，并只扫描本次差异或明确路径，避免结果随上游变化。
Agent PreToolUse
在命令执行前阻止，保护的是当前工作区。它无法替代 CI 对仓库内容的持续检查。
三者解决的时间点不同，可以同时使用。
Allowlist 应怎样管理
某些项目确实需要清理构建目录或重置临时环境。不要关闭整个 dcg，应为范围明确、可验证的命令建立最小例外：
- 只允许项目内特定临时目录；
- 不使用环境变量拼接宽泛根路径；
- 先解析并输出绝对路径；
- 对生产目录不设永久例外；
- 例外进入版本控制和代码评审；
- 定期删除不再需要的规则。
安全例外的目标是缩小误报，不是让 Agent 获得通用绕过通道。
怎样测试而不破坏数据
不要在真实仓库执行 git reset --hard 或递归删除。可使用临时测试仓库和虚拟命令参数，观察 dcg 的解析输出。测试至少包括：
- 普通只读命令被允许；
- 明显危险命令被阻止；
- 目标范围明确的清理命令按预期处理；
- 非法 Hook JSON 不会被静默放行；
- 超时或无法判断时进入人工确认；
- 原有 Hook 仍正常工作。
为什么 Hook 不是完整沙箱
Hook 只能检查它看到的工具调用。以下路径仍可能绕过：
- Agent 写入脚本后由其他进程执行；
- IDE 或插件使用未接入的终端接口；
- 程序通过 API 删除云端资源；
- 容器内命令影响挂载的宿主机目录；
- 凭据泄露后在另一台机器操作；
- 用户主动使用
--no-verify。
因此操作系统权限、容器挂载、云 IAM、备份和审批仍然必须存在。
更新与回滚
可使用：
|
|
团队不应在所有开发机上无计划自动更新规则。先在测试仓库验证新版本的误报和兼容性，再分批升级。回滚需要保留旧版本号和配置备份。
故障排查矩阵
| 现象 | 可能原因 | 处理 |
|---|---|---|
dcg 找不到 |
PATH 未更新 | 新开终端并检查安装目录 |
| Codex 不调用 Hook | 版本或 hooks.json 路径错误 |
检查 /hooks 与配置 |
| 原有 Hook 消失 | 合并异常 | 恢复备份，手工合并 |
| 普通命令被拦截 | 规则误报 | 缩小命令范围并报告案例 |
| 危险脚本未拦截 | 实际执行路径不可见 | 增加 Scan、权限和沙箱 |
| CI 结果不稳定 | 使用浮动版本 | 固定 dcg 版本和规则 |
它不能解决什么
Hook 不是操作系统权限边界。官方也提示，Agent 可以先写入脚本再执行，Codex 的部分统一执行路径可能尚未全部拦截。因此仍需配合：
- 非管理员账户；
- 限定工作目录；
- Git 分支或工作树；
- 重要数据备份；
- 删除和推送操作的人工审批；
- 容器或虚拟机隔离。
常见问题
安装器会覆盖我的 Hooks 吗？
官方实现会尝试合并；若现有 JSON 无效或结构异常，会保留原文件并报告错误。安装前仍应备份配置。
为什么危险命令没有被拦截？
检查命令是否走了受支持的 Hook 路径。若 Agent 把操作封装进脚本、应用内部工具或未覆盖的执行接口，dcg 可能无法看到最终命令。
dcg 会明显拖慢每次命令吗？
项目设计为快速 Hook，并设置绝对处理时间上限。实际延迟仍应在自己的终端和规则集上测量；若明显变慢，检查日志和其他 Hook。
可以只在 CI 安装，不装到开发机吗？
可以扫描仓库内容，但无法在本地 Agent 真正执行命令前拦截。高权限 Agent 环境仍建议配置 PreToolUse Hook。
紧急情况下如何处理误拦截？
先确认命令目标和可恢复性，再由人手动执行或建立最小临时例外。不要让 Agent 自动寻找绕过方法。
总结
dcg 能降低 Agent 误执行危险 Git 和 Shell 命令的概率，尤其适合已经允许 Codex 或 Claude Code 运行终端的环境。但它应被视为安全带，不是保险箱；真正可靠的方案仍是最小权限、目录隔离、备份和人工审批共同生效。