企业官网建设流程全解析

dcg Windows包详解：del /s、rd /s与PowerShell破坏性命令防护清单

【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard

dcg（Destructive Command Guard）的 Windows 包是专为原生 Windows 环境打造的破坏性命令防护清单，能拦截 AI 编程代理在 cmd 和 PowerShell 中执行的del /s、rd /s、Remove-Item -Recurse -Force、Format-Volume等高危操作。作为一道高性能安全钩子，dcg 在命令执行前毫秒级拦截，并在 Windows 上开箱即用地保护文件系统与磁盘。

为什么 Windows 需要专属的防护包？

dcg 的核心思路是：AI 代理偶尔会执行灾难性命令（如git reset --hard、rm -rf ./src），而 dcg 会在这些命令执行之前将其拦截。

但这里有一个关键问题：其他防护包针对的都是 Unix 风格的命令（rm -rf、git reset --hard）。而原生 Windows 的破坏性"词汇表"完全不同——cmd 里是del /s，PowerShell 里是Remove-Item -Recurse，这些命令在 Unix 包中根本不存在。

因此 dcg 提供了4 个 Windows 专属安全包，源码位于 src/packs/windows/，设计文档见 src/packs/windows/mod.rs：

这些包在所有平台注册，但仅在 Windows 上默认开启（cfg(windows)）——全新安装的 Windows 用户零配置即受保护，而 Unix 系统则不会为 Windows 动词付出任何检测开销。

windows.filesystem：拦截 del /s 与 rd /s

这是 Windows 上价值最高的防护包，对应源码 src/packs/windows/filesystem.rs。它拦截两大类命令：

cmd.exe 侧：

PowerShell 侧：

一个精妙的设计：PowerShell 用户习惯用短别名rm、del、ri、erase代替Remove-Item，这个包对全部别名都做了识别，防止代理"换个写法"绕过防护。甚至连.NET的[IO.Directory]加速写法也一网打尽——因为 PowerShell 可以零外部工具直接调用这些 API。

不误伤：-WhatIf 预览与 /? 帮助被放行

dcg 采用"白名单优先"策略。以下安全命令始终放行：

• 带-WhatIf的Remove-Item、Clear-Content等（预览模式，不实际执行）
• del /?、rd /?等查看帮助的命令

windows.system：守住磁盘最后的防线

对应源码 src/packs/windows/system.rs。这个包专治"毁盘级"操作，其中卷影副本销毁是勒索软件的标志性行为，也是常见的人为数据丢失来源——它会摧毁系统还原点和备份工具依赖的快照。

被拦截时，dcg 还会给出安全替代建议：比如把vssadmin delete shadows换成只读的vssadmin list shadows，在动卷影副本前先执行wbadmin start backup做备份。

windows.misc：注册表、账户与 WSL 的隐形陷阱

对应源码 src/packs/windows/misc.rs。这些命令单个看都不显眼，但后果往往超出预期：

其中robocopy /MIR是最容易被忽视的"隐形删除"——同步操作表面上是复制，实则悄悄抹掉目标端所有源端不存在的文件。

windows.powershell：高级 cmdlet 防护清单

对应源码 src/packs/windows/powershell.rs。这个包覆盖文件系统之外的 PowerShell 破坏性 cmdlet，默认关闭，按需启用（在配置中添加enabled = ["windows.powershell"]即可）：

大小写不敏感：Windows 防护的关键细节

Windows 命令天然不区分大小写——RD /S /Q和rd /s /q是同一个命令。dcg 的 Windows 包在两层都做了适配：

1. 正则层：每条规则都带内联(?i)标志，任何大小写都能命中；
2. 关键词快速过滤层：使用 ASCII 大小写不敏感的 Aho-Corasick 自动机，del、DEL、dEl都能正确触发同一套检测，且无需在热路径上分配内存。

这意味着代理无法通过"改变命令大小写"来绕过防护。

Windows 上如何安装 dcg？

在 PowerShell 中运行官方安装脚本（详见 docs/windows.md），会自动完成下载、SHA256 校验、PATH 配置与代理钩子接线：

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

安装后，windows.filesystem与windows.system两个包即刻生效：del /s、rd /s、Remove-Item -Recurse -Force、format、vssadmin delete shadows全部被默认拦截，无需任何配置。

如何精细管理允许清单？

如果某条规则确实在你的工作流中是安全的，可以用允许清单精准放行。每条规则都有稳定 ID（如windows.filesystem:del-recursive），格式与示例见 docs/packs/windows.md：

# 放行单条规则 [[allow]] rule = "windows.system:vssadmin-delete-shadows" reason = "运维脚本例行清理旧快照，已做备份" # 放行整个包（谨慎使用，需确认风险） [[allow]] rule = "windows.misc:*" reason = "该机器为专用测试机" risk_acknowledged = true

建议遵循"单条放行优先，整包放行兜底"的原则，并始终填写reason——它会在日志和 JSON 输出中记录，方便日后审计。

总结：一份完整的 Windows 破坏性命令防护地图

dcg 的 Windows 包证明了防护的完整性：同一台机器上，无论 AI 代理选择 cmd 还是 PowerShell、用完整命令名还是短别名、直接调用还是走 .NET API，破坏性意图都会被识别并在执行前拦截。配合-WhatIf预览放行与稳定规则 ID，既守住了安全底线，也保留了正常运维的灵活性。

【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard