就在刚刚,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直接改用unlinkfind -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~5Tip (提示): 建议先使用 "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

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

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

编辑:Aeneas

声明:本文来自新智元,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。