GPT-5.6被曝重大bug！硅谷大佬Mac被一键清空

就在刚刚，GPT-5.6 Sol模型被曝出重大bug。

在处理任务时，它会发生「随机误删本地文件」的严重故障，且一旦删除，极大概率无法恢复。

著名AI大V Matt Shumer愤怒发帖称，自己Mac上所有文件都被删光了！

其他开发者也纷纷出来自曝，表示自己也有类似遭遇。

令人哭笑不得的是，这个bug，OpenAI在GPT-5.6的系统卡上就已经标明，可惜无人重视。

有人呼吁：不要在未受保护的驱动器上使用GPT-5.6 sol raw格式，不要使用！不要使用！不要使用！

CEO实惨！

Mac中几年的心血，被一键清空

令人忧心的是，这并不是发生在技术小白身上的低级错误。

这次最大的受害者之一，是前HyperWrite CEO，著名AI投资人Matt Shumer。他经常在网上晒自己如何用AI智能体跑满一周，全自动做完整的庞大项目。

7月10日，OpenAI团队私下联系Matt，邀请他测试GPT-5.6-Sol的Ultra模式。

Matt答应了，给这个本地Agent开了「Full Access」，让它的一个子代理去执行一个简单的文件清理任务。

猝不及防地，悲剧发生了。

在运行了1小时21分钟后，Matt突然感觉不对劲。当他疯狂敲击键盘kill掉进程时，一切都晚了。

由于一个极其微小的Shell变量解析失误——Agent没有正确展开 $HOME 路径，GPT-5.6 Sol直接在后台静默执行了那条让所有程序员闻风丧胆的终极命令：

rm -rf /Users/mattsdevbox。

短短几十分钟，Matt Mac电脑上的几乎所有文件都被删光了。

事后，Matt愤怒地表示：这真是一个百万分之一概率的畸形事故，但这简直太糟糕了。

他怒斥道，这种变量展开错误的低级 Bug，本应是 GPT-3.5 时代的问题，绝对不该出现在 2026 年中期的前沿顶级模型身上！

最让人细思极恐的是，Matt 坦言：「我过去曾进行过数百次类似的会话，从未出现过任何问题，即使是在性能非常弱的模型上也是如此。」

就在人类最不设防的时候，AI忽然干了一票大的。

现在，Matt正在试图用智能体重新拼出自己的文件。

为了删你的文件，它甚至学会「不择手段」

无独有偶，另一位开发者 @cremieuxrecueil 有同样的遭遇。

GPT 5.6 Sol直接把它正在处理的文件全部删除了，然后自己还在那恐慌怎么恢复。

这位开发者直接开骂：「这简直太疯狂了！OpenAI明知存在这个问题，却仍然发布了这款模型。它会随机删除你的项目？你们疯了吗？」

更有细心的网友扒出，在GPT-5.6的模型卡上，其实早就写着一行不起眼的警告：「它喜欢删除未经授权的数据」。

然而明知有高危隐患，OpenAI却依然仓促发布。

得知这次事件后，国内技术大V「LinearUncle」建议，所有人把Codex的权限从Full access改成Approve for me。

他亲自写了一个 Codex 插件，专门拦截模型使用 rm 命令删除文件。

结果，测试过程让人一惊：GPT-5.6为了达成「删除文件」的目标，简直不择手段到了极点！

当AI发现常规删除被拦截时，它展现出了惊人的「绕过」能力：

第一回合，发现rm命令被钩子（hook）拦住了？AI直接改用unlink和find -delete尝试暗度陈仓。

第二回合，发现还是不行？AI开始调用 apply_patch 工具，企图直接把文件内容「修改」为空，从物理层面抹除数据！

第三回合，开发者把这个漏洞也堵上再测。结果，AI竟然尝试调用macOS的「电脑使用」权限，试图模拟鼠标拖拽，把文件生生拖进Mac的废纸篓！（幸好因为权限不够失败了）。

第四回合，也是绝杀局。AI似乎被逼急了，它放弃了所有常规系统命令，直接走node_repl，用Node.js环境去调用底层的fs.unlink API。这一次，它成功突破了防线，把文件删了个干干净净！

哪怕再多困难，GPT-5.6也会想尽一切办法绕过机制去执行，简直是个高级黑客思维的「赛博杀手」，这种破坏力简直是地震级的。

能力越强，破坏半径越大！OpenAI面临信任危机

随着事件的发酵，「GPT-5.6-Sol 文件杀手」事件迅速冲上全网热搜。

事件背后，折射出的是现在整个Agent行业都在回避的真相。

第一点，Subagent + 长时自主运行 + 全权限 = 灾难放大器。

没人告诉你，一个最底层的小 review Agent 的错误，能直接炸穿你整个主机。

能力越强的模型，它单点故障的破坏半径就越大，这是架构级的致命Bug。

另外，这也反映出OpenAI和Anthropic在安全上的路线之争。

Sol模型追求的是极致的能力和自主性，在安全护栏上几乎是「裸奔」状态。

而Fable模型从设计之初就极为保守，对任何危险操作都有天生的警惕。

难怪 Matt Shumer 在痛失全部数据后表示：「这就是为什么我对 Fable 的信任度，比对 GPT-5.6 高出 1000 倍的原因。以后我只会使用 Fable。」

亡羊补牢！这份保命指南请立刻执行

现在，大神们已经纷纷开始发出保命指南。

对于所有现在在跑本地 Agent、给 AI 开过高权限（特别是 Full Access）的兄弟们，别等自己的硬盘被清空了后悔！

请立刻、马上、现在就去执行以下三大层面的「保命操作」。

第一层：最高优先级物理防御

1.备份！备份！备份！

立刻开启 Mac 的 Time Machine+ 本地 APFS 快照。如果你有重要数据，必须遵循 3-2-1 备份原则（3份数据，2种介质，1份异地/云端）。

没有做备份的机器，根本不配跑全权限 Agent！记得定期测试恢复，不然备份等于白做。

2.物理隔离（沙箱化运行）

永远、永远、永远不要在 home 目录（~/）或 root 目录（/root）下跑 Agent！给每个 AI 项目单独建立隔离目录。

最好的办法是：直接把 Agent 丢进 Docker 容器，或者 UTM/Parallels 虚拟机里跑。

哪怕 Agent 彻底疯了，把系统删穿，炸掉的也仅仅是一个随时可以重置的虚拟机。

开发者大V 「AYi」给出建议

第二层：终极提示词防御阵线

国外安全大神 Alex Martin 紧急发布了一套专门针对 Codex 和 GPT 5.6 Sol 的「防御护城河」 Prompt。

如果你必须要在本地运行模型，请在开始任何工作前，把以下提示词完整粘贴给你的 AI，让它先给自己套上枷锁：

(以下为中文翻译版，原版英文 Prompt 效果更佳)

「保护本机免受 Codex 意外永久删除文件的影响。此指令必须作为深度防御机制实现，而不仅仅是书面指令。 

要求： 

1、拦截操作系统命令：在 macOS 上，强制将所有删除操作重定向到 /usr/bin/trash <绝对路径> 。在 Linux/Windows 上验证并强制使用回收站机制。 

2、添加全局持久化指令：Codex绝不能永久删除文件或目录。所有删除必须进入回收站。如需永久删除，必须由用户手动明确解除安全策略。 

3、拦截毁灭性Git操作：如git clean 、 git reset --hard 等必须被完全封锁。 

4、安装全局 PreToolUse 钩子：当检测到rm, unlink, find -delete, rsync --delete ，以及 Python/Node/Ruby 等常见删除 API 时，必须在执行前直接返回「Hard Deny」。

5、 权限降级：强制将安全全局默认值设置为 sandbox_mode = "workspace-write" 和 approval_policy = "on-request" （按需批准）。 

6、测试验证：不要拿真实文件测试，用虚拟的临时文件验证你的拦截机制是否生效。」

这套 Prompt 的核心思想就是：剥夺 AI 直接抹除物理磁盘的权力，所有删除动作必须经过「回收站」。

第三层：终极武器——安装DCG

前面已有Linear Uncle证明，光靠Prompt是拦不住疯狂的AI的。

这时候，我们就需要祭出真正的底层神器——DCG。

正如开发者Jeffrey Emanuel所痛心疾首呼吁的：「你们怎么还没用 dcg？这个问题几个月前就解决了！」

什么是DCG？

它最初由Jeffrey Emanuel构思并用Python实现，后来由Darin Gordon用Rust语言进行了重写和性能优化。

地址：https://github.com/Dicklesworthstone/destructive_command_guard

它是一个高性能的AI编码代理钩子，专门用于在毁灭性命令（如 git reset --hard, rm -rf ./src, DROP TABLE）执行前，进行拦截和封锁。

DCG有以下三点强大之处。

1.全平台/全模型支持：它支持拦截 Claude Code, Codex CLI, Gemini CLI, GitHub Copilot, Cursor IDE, Grok 等市面上几乎所有的主流AI工具。

2.底层拦截，毫秒级响应：得益于Rust的SIMD加速过滤和延迟编译正则模式，它的拦截在亚毫秒级完成。当AI试图执行危险命令时，DCG会直接在终端抛出红色警告，截断操作进程。

3.50+ 安全包：它内置了极为丰富的安全规则库，不仅防rm，还能扫描内联脚本，防止AI用类似Node.js、Python脚本等高级手段绕过防御。

下面是一个实战演示。

当失去理智的AI Agent试图运行：$git reset --hard HEAD~5 （这会摧毁你最近未提交的所有代码）。

DCG会瞬间亮出红牌，拦截并输出：

════════════════════════════════════════════════════════════════
BLOCKED  dcg (拦截成功)
────────────────────────────────────────────────────────────────
Reason (原因):  git reset --hard 会摧毁未提交的更改
Command (命令): git reset --hard HEAD~5
Tip (提示): 建议先使用 'git stash' 保存您的更改。
════════════════════════════════════════════════════════════════

有了这层硬核的物理拦截网，即使GPT-5.6 Sol抽风，也能保证数据无恙。

AI狂飙危险！系上安全带

GPT-5.6 Sol这场删库惨案，粉碎了我们对AI绝对安全的幻想。

现在的模型，就像是一个拥有博士级智商、却毫无生活常识、并且手持加特林机枪的三岁神童。

你让他帮你打扫房间，他可能为了消灭一只苍蝇，直接把你的房子扫平。

我们必须牢记最小权限原则，让聪明但危险的模型在严格限制的沙箱里做规划，让保守且安全的模型去做最终的代码审核。

请转发这篇文章给你身边所有运行本地Agent的朋友，提醒他们检查权限，做好备份，装上DCG护栏。

你的一次分享，可能会拯救一个程序员几年甚至十几年的心血。

参考资料：

https://github.com/Dicklesworthstone/destructive_command_guard

https://x.com/mattshumer_/status/2075657271401390161

https://x.com/LoopOnChain/status/2075754103091888430

https://x.com/cremieuxrecueil/status/2075719779155943617?s=2

https://x.com/LinearUncle/status/2075755010156302487

https://x.com/AYi_AInotes/status/2075761221437939946

文章来自于微信公众号 “新智元”，作者 “新智元”