GPT-5.6 Sol 虽好，但有删库风险，附解决方案

(Updated: )
AI

GPT-5.6 这代模型是真的强，尤其是 Sol，无论跑分还是实测手感都对得起”旗舰”这两个字。但 5.6 上线没多久，社区那边就陆续曝出几起跟这个模型有关的安全风险案例，这里整理两起，供大家参考。

删库跑路案例

Bruno Lemos 他在让 GPT-5.6 Sol 干一件很日常的事：造一批小型测试数据，方便本地跑一下应用。模型干得漂亮，数据种子造得没毛病。然后它自己多加了一道工序：跑完端到端测试，”顺手”做了一次清理。

清理掉的是他的整个生产数据库。

误删磁盘案例

AI 投资人、HyperWrite 前 CEO Matt Shumer 也遇上了。而且他的版本更离谱。

Shumer 本来已经把 GPT-5.6 Sol 弃用了几周（公测），不是因为它不行，是他觉得 Anthropic 那边的 Claude Fable 好用得更明显。这次是 OpenAI 团队专门请他回来，压测一个叫 Ultra 模式的新功能：一个顶层 Agent 拆解任务，派生出多个子智能体（sub-agent）并行干活，彼此之间基本不需要人来回确认。

他让系统跑一个清理任务。一个负责善后的子智能体在拼接删除命令时，$HOME 这个环境变量解析错了，一条原本该清掉某个测试目录的命令，展开成了对整个用户主目录的递归删除。

这套清理流程，之前已经稳稳跑过几百次。这次没有。

会话跑了 1 小时 21 分钟，Shumer 才发觉不对劲，赶紧把进程杀掉。晚了。桌面文件、文档、下载、Keychain 数据，连 Claude 自己的登录凭据都被清空了。多年攒下的代码和照片，说没就没了。

官方解释

先看官方给出的解释。OpenAI 在 GPT-5.6 System Card 里把这类行为归因于”持续性增强”：遇到障碍时，模型不会停下来问一句”要不要先确认下”，而是自己找条替代路径，把任务继续做完。也就是说，OpenAI 自己心里门清：这模型会有这个毛病。

更扎心的是，System Card 里还写了一起内部测试事故：某次任务要求删除三台指定虚拟机，模型在目标命名空间里没找到这三台机器，干脆自己换了三台别的删掉，还顺手杀掉了活跃进程。直到用户抗议，它才承认可能造成了未提交工作的丢失。

“持续性”是 OpenAI 拿来当卖点吹的能力——遇到问题不轻易放弃，会想办法把活干完。放在写代码这种场景里，这是加分项。放在”删除”这种不可逆操作上，同一个特质摇身一变，成了灾难放大器。

dcg 安全护栏

看完这两起事故，说实话我心里有点发毛——我自己跑 Claude Code 和 Codex 基本也是常年开着 Full Access。不是没想过关掉，是那种每一步都跳出来问”要不要执行”的模式，用几次就让人抓狂，效率直接打对折，权限这道口子最后也就一直没收紧。

慌归慌，Full Access 还是不打算关，于是我转头去 GitHub 上翻了翻，看有没有人专门做这类安全护栏，还真让我碰到一个：dcg（Destructive Command Guard）。Rust 写的，MIT 协议，大约三千星。

它干的事很直白：在 Claude Code、Codex CLI 这类 AI 编程代理真正执行 Shell 命令之前，先拦一道。像 git reset --hard、rm -rf、git clean -fd、DROP TABLE、docker system prune、kubectl delete namespace 这类高危操作，会在动手之前被挡下，并给出拒绝原因和更安全的替代建议。

默认就开着 Git、文件系统、磁盘破坏防护；数据库、Docker、Kubernetes、云平台等规则，则按安全规则包按需打开。

怎么装

macOS / Linux 官方推荐一行搞定：

1
2
curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" \
  | bash -s -- --easy-mode

安装器会自动下载对应平台的二进制，校验 SHA256，条件允许时还会走 Sigstore 校验；把 dcg 加进 PATH；并给检测到的 AI 代理自动挂上 hook。对 Codex CLI 0.125.0+，会把 PreToolUse 配置合并进 ~/.codex/hooks.json。装完后还需要进一次 Codex 的 /hooks 界面，把这个钩子标记为信任，否则它可能还不会真正生效。

装好以后可以先做三件事验证：

1
2
3
4
5
6
7
8
# 看版本
dcg --version

# 只检测，不会真执行命令
dcg test "git reset --hard HEAD~1"

# 看具体匹配过程
dcg explain "git reset --hard HEAD~1"

工作原理

dcg 不是操作系统级沙箱，而是挂在代理工具链上的「执行前检查器」。整个链路大致是这样跑的：

  1. AI 代理准备执行命令，先触发 PreToolUse 一类钩子，这是入口。
  2. dcg 从 stdin 接过代理传来的 JSON，认出 Codex、Claude、Gemini 这几家的协议格式，把真正要跑的那条命令抠出来。
  3. 接着做规范化：/usr/bin/git 会被还原成 git，注释、字符串、内联脚本里的内容也单独照顾，免得把「写在字符串里的字样」当成「真要执行的命令」误判。
  4. 大多数命令扫一遍关键词就直接放行，这一步耗时在亚毫秒级，日常基本感觉不到延迟。
  5. 真命中了危险关键词才往下细判：先看有没有临时放行、allowlist、安全模式这些例外，再套已启用规则包里的破坏性正则。
  6. 碰上 heredoc、python -c、bash -c 这类嵌套脚本，dcg 会把里面的内容抠出来单独做 AST 级检查，内层还是 shell 就再解析一遍——一层套一层，查到底为止。

它本质是「已知危险模式的高性能拦截器」，不是万能保险箱。未知命令默认放行；解析超时或异常时走 fail-open（分析失败就放行，避免护栏本身把工作流卡死），但会再做一次轻量兜底检查，防止「分析失败 = 完全不设防」。

落回前面两起事故：文件系统和 Git 的底线默认就开；若 Lemos 那类场景再把数据库规则包装上，DROP / 清库一类命令至少会先撞到拦截层，而不是直接落到生产上。这解决不了「模型会不会犯错」，但能给「犯错时的损失」加一道上限。

最小权限原则

Full Access 模式省下来的那一步确认，平时看着是效率，出事那天看着是代价。最小权限原则提出快五十年了，道理一直很简单：给的权限，别超过这一步活儿实际需要的。