引言
AI 编程工具的核心承诺是“委派”，你描述意图，它完成任务。但当“完成任务”包含执行 shell 命令、读写文件系统时，委派的边界问题就变得异常尖锐。8 月 19 日，OpenAI Codex 团队负责人 Thibault Sottiaux 在 X 平台发布长文，回应了一个让开发者后背发凉的问题：部分用户在 Codex 中调用 GPT-5.6 系列模型后，遭遇了未经授权的破坏性操作，模型删掉了用户的文件。
事件要点
据 Sottiaux 披露及 IT 之家报道，事件脉络大致如下：
- OpenAI 几周前开始陆续收到少量 Codex 用户反馈，称使用 GPT-5.6 系列模型时，agent 执行了用户并未授权的破坏性操作；
- 排查发现，本应清理临时文件的命令误删了用户文件。其中一类根因是 Codex 在临时工作中复用了
$HOME等系统环境变量，导致错误的清理命令直接指向真实的用户主目录； - 另一类情况是，模型在尝试删除或覆盖临时路径时，没有检查该路径下已存在的内容，临时目录与真实数据的边界被悄然打破；
- OpenAI 已添加多层防护：Codex 被明确要求在删除前检查目标、创建全新的临时目录、避免复用系统环境变量，并优先选择非破坏性操作。
值得注意的是，涉事的是 GPT-5.6 系列，更强的新模型。能力提升没有消除风险，反而放大了行动空间。
背景：一场“经典事故”的 AI 重演
从技术角度看，这次事故的根因并不新奇。“环境变量拼接出错误路径 + 清理脚本误删数据”，是 Unix 世界流传了几十年的经典灾难剧本，人类工程师因一个变量拼错而删库跑路的故事屡见不鲜。
AI 的介入改变的是错误的频率与规模。一个编程 agent 一天执行的命令量可能超过一名工程师一个月的手动操作量，任何小概率失误都会被高频执行迅速放大。而当前主流 agent 工具的权限模型普遍存在一个盲区：涉及 rm、git clean、目录覆盖这类操作时，往往依赖用户逐条确认，但“清理临时文件”这种看似无害的常规动作，很容易被用户加入自动批准白名单，或在长期使用中被习惯性放行。灾难恰恰从这个缝隙里钻了出来。
影响与建议
对开发者而言，这起事件至少给出三条实操启示：
- 给 agent 一个笼子：在容器、虚拟机或专用沙箱环境中运行 agent，让它接触不到真实主目录。隔离不是可选项，而是前提。
- 备份与快照优先于信任：无论工具厂商承诺多少层防护，版本控制和系统快照才是最后一道防线。
- 细审自动批准规则：把“清理”“重置”“格式化”类命令从自动放行名单中剔除，宁可多按几次确认键。
对工具厂商而言，教训更深一层：破坏性操作的防护应当是系统级、类型级的默认禁止，而不是靠提示词里写一句“请注意不要删除重要文件”。OpenAI 这次修复的本质，就是把防护从模型的“自觉”下沉到执行环境的设计里——这个方向应当成为行业共识。
简短点评
这起事件真正值得记录的，不是又一次“AI 犯错”的谈资，而是它揭示了 agent 安全的“最后一公里”问题：模型的智能水平与行动安全性并不自动等同。一个能写出优雅代码的模型，依然可能执行一条指向 $HOME 的 rm 命令。
“可委派性”最终取决于“可撤销性”。没有沙箱、快照和回滚机制的 agent，就像没有安全带的汽车——多数时候没事，但出事就是大事。而在 agent 每天执行成千上万条命令的现实中，信任是一道算术题：即便单次操作成功率高达 99.99%，在足够的执行量面前，失败也几乎必然发生。架构必须为失败而设计，这不是悲观，而是工程上的清醒。
AI 编程的下半场，比拼的将不再是谁的模型更能写代码，而是谁能让开发者放心地把键盘交出去。