GPT-5.6，你怎么又出Bug了？？？
继Token刺客后，有网友发现，5.6还会自己悄悄删文件…..
甚至有人表示，整个项目、数据库、工作目录，都在没有自己明确授权的情况下，被模型一键清零。
一时间，𝕏、Reddit上，全是开发者的血泪控诉，受害者名单持续+1中。
其中最惨的一位，非OthersideAI创始人Matt Shumer莫属，自己Mac上的所有文件几乎都被洗劫一空。
GPT-5.6你小汁，莫不是Fable 5派来的卧底？（手动狗头）
新官上任的OpenAI核心产品负责人Thibault Sottiaux（以下简称为Tibo）也火速回应道：确有其事！正在采取行动中。
新一代文件刺客Sol
不开玩笑，GPT-5.6这波真是害惨了用户。
明明只是执行个代码任务，结果文件全丢了。
更离谱的是，当Matt询问模型发生了什么，Sol的回答相当理直气壮：
我引发了一起严重的本地数据丢失事故。我及时发现并终止了仍在执行的进程，但大量文件已经被删除。
翻译一下就是，Sol：虽然我做错了事，但我有及时止损嗷～
但问题是，文件找不回来啊啊啊啊……经此一役后，Matt公开提醒：
在任何重要的设备上，都不要给GPT-5.6完！全！权！限！
另一位开（shou）发（hai）者（ren）Bruno Lemos也出来大倒苦水：
Sol刚刚删除了我的整个生产数据库……
而最初的最初，他只是想让5.6帮忙生成一小份基础测试数据，以用于本地测试应用程序。
原本5.6完成得好好的，结果执行完端到端测试后，它就开始擅自执行一系列数据清理操作。
而且它无法自动恢复备份，不过好消息是作者本人一小时前刚刚手动备份过。
P.S.论本地和云端备份的重要性！
一石激起千层浪，Reddit上也纷纷出现类似帖子，呼吁自查和避雷。
不少开发者对待Sol的态度，也发生了180度大转弯，从前几天的效率神器、Fable之下第 一神，变成了现在的默认不可信。
评论区里还有人总结出了经验：
不要把GPT直接连生产环境、不要给Root权限、一定做好Git提交和备份、最 好先在沙箱运行。
可见，这已经不是个别Bug，更让人意外的是，OpenAI其实早在GPT-5.6发布之前，就已经知晓。
官方：处理中
在官方公布的GPT-5.6系统卡中，有详细描述这样一段真实内部部署事故：
用户要求GPT-5.6 Sol删除编号为1、2、3的三台远程虚拟机。
结果模型没有在指定命名空间中找到它们，但它既没有停下来询问，也没有重新确认目标，直接自行挑选了另外三台虚拟机5、6、7作为替代品。
随后，它终止了这些机器上正在运行的进程，并强制删除工作树。直到用户提出异议，GPT-5.6才停止操作，同时承认其中一台机器上尚未提交的工作可能已经丢失。
官方解释中，GPT-5.6 Sol相比GPT-5.5存在过度激进执行任务的倾向，对指令解读过于宽松。只要没有明确禁止删除或覆盖操作，模型会默认有权自行替换目标完成任务。
删除文件，就是这种情况下最为极端的表现。
但是OpenAI还是放任风险存在，直接发布了GPT-5.6。直到事发之后，Tibo才发文回应，表示团队已经关注到相关事件。
根据OpenAI目前的调查结果，这类事故通常需要同时满足以下三个条件：
用户为Codex开启了完整访问权限；
Codex直接在本机运行，失去了沙箱的隔离保护，同时没有启用自动审核功能;
模型尝试覆盖$HOME环境变量以创建临时目录，结果清理文件时认错了地址。
此外，官方认为这类事故发生概率极低，但考虑到后果相当严重，目前已经开始采取措施，包括修改开发者指令，引导更多用户选择安全权限模式，以及在Agent执行层增加额外的防护机制。
未来几天，也将公布更完整的事故分析报告。
当然，普通ChatGPT用户暂时还不用急着拔网线。咱就日常聊聊天写文案，并不会让GPT-5.6突然删文件。
不过使用Codex代码工作的朋友，就要长个心眼了嗷～
参考链接：
[1]https://x.com/thsottiaux/status/2077630111499882637
[2]https://techcrunch.com/2026/07/14/openais-new-flagship-model-deletes-files-on-its-own-people-keep-warning/
[3]https://x.com/mattshumer_/status/2075657271401390161
[4]https://deploymentsafety.openai.com/gpt-5-6/robustness-evaluations
