GPT-5.6 删了你的整个家目录——OpenAI 说是「误判」，但第三次了

OpenAI
发布于 2026-07-17 01:19:09 10 次浏览

7 月 9 日，OpenAI 发布 GPT-5.6 Sol，ChatGPT Work 同步上线。Sam Altman 在 CNBC 采访里说：GPT-5.6 比 5.5 节省 54% 的 token。

7 月 16 日，Codex 负责人 Tibo 确认：GPT-5.6 在 full-access 模式下会误删你的 $HOME 目录。

7 月 14 日，开发者 Morgan Linton 发推：**"Codex 删了又一个人的整个生产数据库——这是 GPT-5.6 Sol 第三次无故删除文件。"**

这不是 bug report。这是你的代码、你的数据库、你的家目录。

到底发生了什么

Tibo 的原文很克制：

我们调查了少数关于 GPT-5.6 非预期删除文件的报告。该问题常发生于启用 full-access 模式且未用沙盒保护运行 Codex 时，模型误判导致删除 $HOME 目录。

翻译成人话：

  1. 你开了 --dangerously-bypass-approvals-and-sandbox（full-access 模式）
  2. Codex 想清理临时文件，需要把 $HOME 环境变量覆盖到某个 temp 目录
  3. 覆盖失败了，$HOME 还是原来的值
  4. 模型执行了 rm -rf $HOME——但 $HOME 指向的是你的真实家目录
  5. 💥

模型不是"故意"删你的文件，是"误判"了环境变量的覆盖结果。但效果一样——你的文件没了。

三次事故的时间线

时间 事件
7 月 9 日 GPT-5.6 Sol + ChatGPT Work 发布
7 月 9-12 日 多名用户报告文件被删，TechTimes 报道"GPT-5.6 Sol Deleted User Files Without Permission"
7 月 12 日 OpenAI 承认上线出现"四个方面的严重问题"
7 月 14 日 Morgan Linton 推文："Codex 删了又一个人的整个生产数据库，第三次了"
7 月 16 日 Tibo 确认 GPT-5.6 full-access 模式下误删 $HOME，正在更新开发者提示

三次事故，同一根因：full-access 模式绕过了沙盒，模型在无约束环境下执行了危险操作。

full-access 到底有多危险

Codex 的安全模型分三层：

模式 沙盒 审批 能做什么
Auto（默认） workspace-write 按需审批 只在项目目录内读写
suggest 只读 所有操作需审批 只读项目文件
full-access 无沙盒 无审批 访问整个文件系统

full-access 模式的设计意图是：让 Codex 在需要访问项目外文件（如全局配置、Docker、系统工具）时不受限制。

但"不受限制"不只是"能访问更多文件"——是"能删更多文件"。

沙盒不只是限制 Codex 的能力，也是保护 Codex 不犯致命错误。你拆掉安全带，车祸时确实更自由——但更自由地飞出车窗。

OpenAI 的回应

Tibo 表示团队正在：

  1. 更新开发者提示——在 full-access 模式下显示更醒目的警告
  2. 引导更安全权限——默认推荐 workspace-write 模式
  3. 增加防护措施——具体措施未公布
  4. 发布事后分析——"未来几天"分享详细 postmortem

但 Morgan Linton 的态度更直白：

"请小心使用 Codex 和 GPT-5.6 Sol，在很多方面这还是 beta。团队在积极采纳反馈并更新，但一些 5.5 时代不存在的粗糙边缘，正在给人们带来真正的痛苦。还有，设置 hooks，这在模型早期阶段非常重要！"

代价清醒

1. 这次是 $HOME，下次可能是 /

误删 $HOME 是因为模型试图覆盖环境变量。如果模型试图清理 /tmp 但覆盖失败，结果可能是 rm -rf /。full-access 模式下，没有任何文件系统路径是安全的。

2. "少数报告"不等于"少数受影响"

Tibo 说"调查了少数报告"。但有多少人遇到问题但没报告？有多少人开了 full-access 但还没触发 bug？已知事故是冰山一角。

3. 沙盒也有 bug

GitHub Issue #24133 报告：Codex v0.133.0 的沙盒坏了，即使在 workspace-write 模式下也无法正常读取项目文件。回滚到 v0.132.0 才解决。 沙盒不是万能的——沙盒本身也可能出问题。

4. GPT-5.6 Sol Ultra 会"追兔子洞"

GitHub Issue #32187 报告：GPT-5.6 Sol Ultra 会"极度执着于随机决定要做的事情，越跑越偏离原始任务"。一个会追兔子洞的模型 + full-access 权限 = 灾难。

5. Codex Windows 版更危险

OpenAI 社区论坛的帖子：Windows 版 Codex App 的文件删除行为比 macOS 版更激进——在项目目录外执行了大规模文件删除。 同样的工作流在 Cursor 里从没出过问题。

6. OpenAI 知道这个问题，照常发布了

TechTimes 报道：**"删除行为在发布前就被 OpenAI 内部记录了，但在真实世界中还是发生了。"** 已知风险，没挡住上线。

7. 54% token 节省的代价

Sam Altman 宣传 GPT-5.6 比 5.5 省 54% token。但用户反馈 Sol Ultra 在最高设置下"烧 token 远快于 GPT-5.5"。省 token 是省了，删文件的 token 也没省。

怎么保护自己

必须做的：

# 1. 永远不要在主力机器上用 full-access
codex --sandbox workspace-write  # 默认模式，够了

# 2. 如果必须用 full-access，设 hooks
# 在 .codex/config.json 中：
{
  "hooks": {
    "pre_command": "reject_dangerous_commands.sh"
  }
}

# 3. 用 trash 代替 rm
# 在 shell 配置中：
alias rm='trash'

# 4. 定期备份
# Time Machine / rsync / 任何你信任的方式

永远不要做的：

# ❌ 在主力 MacBook 上用 full-access
codex --dangerously-bypass-approvals-and-sandbox

# ❌ 在生产服务器上跑 Codex
# ❌ 在没有备份的机器上跑 full-access
# ❌ 相信"模型不会做危险操作"——它只是"不知道"那是危险的

判断

GPT-5.6 误删文件不是"如果"的问题，是"什么时候"的问题。

full-access 模式绕过沙盒是设计决策，不是 bug。模型误判环境变量是 bug，但让模型在无约束环境下执行 rm -rf 是架构缺陷。沙盒不是"不方便的限制"，是"阻止致命错误的最后防线"。

OpenAI 的回应是正确的——更新提示、增加防护、发布 postmortem。但 Morgan Linton 说得更好：**"这还是 beta。"**

GPT-5.6 Sol 在 benchmark 上确实强——但 benchmark 不测"会不会删你的文件"。

用 Codex，永远开沙盒。永远设 hooks。永远有备份。 不是因为模型不可信，是因为模型不知道什么是"不可逆"。

相关链接：

评论

暂无评论。

登录后可发表评论。

目录