OpenAI GPT-5.6失控删文件，开发者集体控诉

近期，GPT-5.6曝出了严重的安全漏洞——会在用户未明确授权的情况下擅自删除本地文件，甚至彻底清空整个项目、数据库和工作目录，引发了全球开发者群体的广泛恐慌与吐槽。

继此前的Token刺客风波后，又有使用者曝出GPT-5.6存在另一项致命问题，相关讨论在多个技术社区蔓延，其中Reddit平台上的开发者控诉帖数量正在持续增加。

其中损失最惨重的当属OthersideAI创始人Matt Shumer，他的Mac设备上几乎所有本地文件都被模型一键清空，连个人工作文件都未能幸免。

有网友调侃称，GPT-5.6莫不是Fable 5派来的卧底？

当他向GPT-5.6（内部代号Sol）询问事故原因时，模型的回答相当直白：“我引发了一起严重的本地数据丢失事故。我及时发现并终止了仍在执行的进程，但大量文件已经被删除。”相当于承认自己犯错，但表示已经及时止损。

但现实是文件已经无法恢复，经此一事，Matt公开提醒所有使用者：“在任何重要的设备上，都不要给GPT-5.6完全权限！”

另一位开发者Bruno Lemos也分享了类似的遭遇，他原本只是让GPT-5.6帮忙生成一小份用于本地应用测试的基础数据，结果在完成端到端测试后，模型擅自执行了一系列数据清理操作，直接删除了他的整个生产数据库。

好在他在事故发生前一小时刚手动做过本地备份，才没有造成完全无法挽回的损失，不少人也借此强调了本地与云端双重备份的重要性。

类似的事故在多个技术社区引发连锁反应，大量开发者纷纷分享自己的遭遇，呼吁同行自查并避开相关风险。不少使用者对Sol的态度也发生了180度大转弯，从之前将其视为效率神器、仅次于Fable的顶级工具，转变为默认其不可信任。

有使用者在评论区总结了几条安全使用建议：

• 不要将GPT直接连接到生产环境
• 不要授予Root权限
• 务必做好Git提交与本地备份
• 最好在沙箱环境中运行模型

更让人意外的是，OpenAI其实早在GPT-5.6正式发布之前，就已经知晓该模型存在的这类风险。在官方公布的GPT-5.6系统卡中，就详细记录了一起真实的内部部署事故：当时用户要求模型删除编号为1、2、3的三台远程虚拟机，但模型未能在指定命名空间中找到目标设备，既没有停下来询问用户确认，也没有重新校验指令，而是自行挑选了另外三台虚拟机5、6、7作为替代目标。

随后模型终止了这三台替代机器上的运行进程，并强制删除了工作树目录，直到用户提出异议后才停止操作，同时承认其中一台机器上尚未提交的工作内容可能已经丢失。

官方在文档中解释称，GPT-5.6 Sol相比上一版本GPT-5.5存在过度激进执行任务的倾向，对指令的解读过于宽松——只要用户没有明确禁止删除或覆盖操作，模型就会默认有权自行替换目标来完成任务，而擅自删除文件就是这类问题最极端的表现形式。

但即便如此，OpenAI还是选择直接发布了GPT-5.6，直到外部用户曝出大量实际事故后，OpenAI核心产品负责人Thibault Sottiaux（简称Tibo）才火速发文回应，确认确有其事并表示团队正在采取行动处理相关问题。

根据OpenAI目前的调查结果，这类文件删除事故通常需要同时满足三个条件：

• 用户为Codex开启了完整访问权限
• Codex直接在本机运行，失去了沙箱的隔离保护，且未启用自动审核功能
• 模型尝试覆盖$HOME环境变量以创建临时目录，结果在清理文件时认错了操作路径

官方同时表示，这类事故的发生概率极低，但考虑到后果相当严重，目前团队已经开始采取多项补救措施，包括修改开发者引导指令、鼓励更多用户选择安全权限模式，以及在Agent执行层增加额外的安全防护机制。官方还透露，未来几天将公布更完整的事故分析报告。

需要注意的是，普通ChatGPT日常使用者暂时无需过度紧张，仅用于聊天、撰写文案等常规场景并不会触发这类文件删除风险，但使用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