在 AI 编码代理跑命令之前把它拦下来——cc-safety-net 的拦截边界
让 AI 编码代理自主执行命令，最让人不安的不是它写得对不对，而是它会不会在你没看清的那一行里，把 git reset --hard、rm -rf 或 ~/.ssh/id_rsa 顺手用掉。CC Safety Net（页面中文名「命令安全护栏」）针对的正是这一小段空隙：在工具调用真正运行之前，先判断这条调用会做什么，再决定放行还是拦下。
它由 kenryu42 维护，MIT 许可。本站详情页记录 GitHub 星标 1,568、综合分 69.7，并已于 0 天前在 dsh 0.2.0-rc.2 下真实安装成功（L4 · 真实安装）；npm 包站点记录 2.5.0，registry 上 latest 已是 2.5.1。真正决定它值不值得装的，是它的拦截边界划在哪里。
它拦在什么位置：工具调用之前的语义判定
官方文档把工作方式讲得很清楚：它解析命令实际会做什么（"It parses what the command does"）。对象不是「命令字符串长什么样」，而是「这条命令落下去会产生什么后果」。README 那句 "Wrapping the command or reordering flags does not hide it" 说的就是这个——把危险命令包一层、把参数顺序调换一下，都不构成绕过。
工程上的意义是：它卡在 Agent 的工具调用链路上，而不是卡在终端里。一次调用被 deny 后根本不会执行，Agent 还会收到「为什么被拦」的说明。
两条拦截路径：破坏性命令与敏感文件
第一条是破坏性命令。它点名了 git reset --hard、git push --force、以及对危险目标的 rm -rf；文档还列出 find -delete 与 PowerShell 的 Remove-Item。关键在于：同一条命令写在 bash -c 或 python -c 里照样拦得住——塞进解释器的一行代码并不能把它藏起来。
第二条是敏感文件访问。SSH 密钥、.env、~/.aws，以及各编码 CLI 自己保存的凭据文件都在覆盖范围内，而且同时管 shell 与 Agent 自带的读、写、编辑、搜索工具两条路。CLI 自身设置文件的拦截是可选项，默认关闭。
坑一：它不是沙箱，这两件事它管不了
现象。 装完之后容易产生「现在随便让 Agent 跑，反正有护栏兜着」的安全感，于是把危险操作直接交给它。
原因。 README 原文很直白：It is not a sandbox: it does not contain processes, set filesystem permissions, or watch network egress——不隔离进程、不设文件系统权限、不监听网络出网。它能挡的是「它认得出来的破坏性命令与敏感文件访问」，挡不住进程自己发起的任意出网，也挡不住权限配置本身出错。
解决。 把它当成一道「执行前的语义关卡」，而不是隔离环境。真要强隔离，仍是容器、虚拟机、受限权限上场。
坑二：配置坏掉时，它什么都不拦
现象。 某天改完配置，一切看起来照常，命令该跑还是跑——直到某条本该被拦的命令真的执行了。
原因。 README 明写 "A broken config file never blocks anything"。坏法包括 YAML/JSON 语法写错、schema 版本对不上、规则文件路径写错。它的失效方式是 fail-open：不报错、不崩，只是静默地什么都不拦。旧的 inline 配置（如 .safety-net.json）运行时也已不再加载，规则等于没生效。
解决。 改完配置后跑自检，别靠感觉：npx cc-safety-net doctor 核对安装与自检，npx cc-safety-net status 看当前在强制执行什么，npx cc-safety-net explain "git reset --hard" 逐条追一条命令的分析过程。
坑三：它能识破包装，但复杂 shell 组合仍是漏判高发区
现象。 试了两条明显危险、又被包装过的命令都被拦下，于是得出「它什么都拦得住」。
原因。 它做的是命令语义层解析，包装命令、换参数顺序躲不掉；但反过来，管道组合、子 shell、脚本里的二次展开，仍是误判与漏判的主要来源。Strict 档会额外拦下「分析器无法安全验证」的动态或不可解析命令，官方也承认这在高级 shell 用法上偶发误报。
解决。 把策略挡位当成与你的 shell 用法匹配的参数，而不是一律拉满。脚本大量使用动态拼接时，先用 explain 看关键命令被判成了什么，再决定放行路径与豁免名单。
坑四：它不审代码质量，别拿它替代测试
现象。 有了护栏之后，可能顺手把「模型写错业务逻辑」也划进它的职责。
原因。 它拦的只有两类东西：破坏性命令，和敏感文件访问。它不判断业务逻辑对不对，不管边界条件，也不管新写的函数有没有覆盖到。
解决。 分工分清：命令护栏负责「别把仓库和密钥搞坏」，测试与评审负责「逻辑写得对不对」，两者互不替代。
三档预设与规则包
npx cc-safety-net gui 会拉起本地网页 GUI，在 Policy 里切换三档预设，并逐条开关规则：
- Standard：拦下可识别的破坏性 Git 与文件系统命令；对内置敏感路径只允许元数据查看，内容访问继续拦。日常编码的推荐档。
- Strict：额外拦下分析器无法安全验证的动态或不可解析命令，并禁止对内置敏感路径做元数据探查；代价是高级 shell 用法偶发误报。
- Paranoid：连项目内部的
rm -rf与解释器单行代码也拦。官方用词是 expect friction——准备好吃摩擦，适合不可信 Agent 或高风险仓库。
规则包是另一条扩展路径，官方覆盖 Terraform、AWS、gcloud、Azure，也可自己写 JSON。一条设计约束值得记住：规则包只能「增加拦截」，不能把内置保护关掉——只能更紧，不能更松。
共享与嵌入：.cc-safety-net/ 与 checkCommand
想让团队或云会话拿到同一套规则，可以把 .cc-safety-net/ 提交进仓库。两个细节容易忽略：光复制文件夹不够，hook 本身仍需安装；若项目文件试图放宽成员更严格的设置，status 与 doctor 会报出来。代价也真实：规则清单（你禁了哪些路径与命令）成为仓库的一部分。
想嵌进自有工具则不必装 hook：装 npm 包后，在 Node.js 里从 cc-safety-net/api 导入 checkCommand，传入命令与绝对路径的 cwd，拿回 allow 或 deny。官方约定：checkCommand 抛错就不要执行那条命令。
它支持 14 个编码 CLI（Amp Code、Antigravity CLI、Claude Code、Codex、Cursor、DeepSeek Harness、Gemini CLI、GitHub Copilot CLI、Grok Build、Hermes Agent、Kimi Code、OpenClaw、OpenCode、Pi），平台覆盖 Windows / macOS / Linux。但别把「支持 14 个」理解成「14 个都长一样」：每个 CLI 有各自的接入要求，README 按 per-CLI 章节分别指向安装文档；只在一个 CLI 上试通就外推到全部，很容易踩空。
另外，本站尚未对该插件做风险分级——详情页静态扫描判定为「含敏感能力」（14 处证据），属能力清单而非危险判定，「暂未覆盖」也不等同于「无风险」。
总结
cc-safety-net 的价值不在于「万能」，而在于把一道语义关卡放在 Agent 执行命令之前：包装命令躲不掉，bash -c 里的危险命令与敏感文件访问照样被拦，但它不是沙箱、配置坏掉会静默失效、也不审代码质量。想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：让 AI 编码代理自主跑命令、又担心误删误推的开发者；需要在 shell 与 Agent 文件工具两条路径上同时挡住 SSH 密钥、.env、~/.aws 的团队；希望把策略提交进仓库、让克隆机器与云会话共用的人。
不适合：指望靠它替代容器或沙箱做进程隔离的人；只装一次就再也不看 doctor/status、无法接受 fail-open 的用法；打算用它替代代码审查与测试的人。
标签：cc-safety-net、DeepSeek Harness、命令安全护栏、AI 编码代理防护、插件避坑
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。