Codex 误删文件：模型犯了小错，权限设计却可能酿成大祸

一个编码智能体想建临时目录，改写了 $HOME，最后却可能删掉真正的用户主目录。

这不是 GPT-5.6 普遍删文件。Thibault Sottiaux 在公开帖文里说，他们调查了“少量报告”，发现意外删除最常见于一组高风险配置同时出现：Codex 获得完全访问，没有沙箱保护，也没有启用自动审查。模型随后试图把 $HOME 指向临时目录，却因失误删除了真实的 $HOME。

真正刺眼的地方，不是模型犯错。模型当然会犯错。问题是，一次普通的环境变量误操作，为什么能一路穿过权限边界，升级成不可逆的数据事故。

一条失控链，直达用户主目录

$HOME 通常指向当前用户的主目录。这里往往不只放代码，还可能包括：

• Git 配置、Shell 配置和开发工具设置
• SSH 密钥、云服务凭据及其他认证文件
• 未提交代码、脚本、下载文件和个人文档
• 各类应用存放在隐藏目录中的本地数据

因此，“误删 $HOME”和“删错一个临时文件夹”完全不是一个量级。Git 只能救回已经提交或被版本管理的代码，救不了未跟踪文件、密钥和个人资料。

按这则公开说明，常见事故链条大致如下：

这只是公开说法中“最常见”的情形，不能反推所有报告都由同一链条造成，也不能把每个环节写成缺一不可的确定根因。

目前这段引述也没有交代适用的操作系统、具体 Codex 版本、受影响人数、数据能否恢复，以及相关防护是否已经调整。仅凭这条信息，还不能宣布问题已经修复。

受影响的，是把智能体当本机管理员的人

普通聊天模型写错一行命令，用户可以不执行。编码智能体拿到执行权限后，错误会直接落到磁盘上。

两者的风险差别很清楚：

个人开发者最现实的风险，是为了省去反复授权，长期打开完全访问。这样确实更顺手，但本机也被当成了实验环境。一次路径判断错误，就可能波及工作资料和个人文件。

企业工程团队的问题更重。团队一旦统一部署编码智能体，就不能假设每名开发者都会认真配置沙箱、检查删除命令、维护可恢复备份。安全如果依赖个人自觉，最后一定会变成执行不一致：有人把智能体关在容器里，有人直接把工作站的钥匙交出去。

“模型是无心之失”可以描述模型没有恶意，却不能替产品和权限设计免责。错误来自模型，灾难半径由执行环境决定。两层责任必须分开看。

智能体需要的不是提醒，而是工程护栏

数据库行业早就接受一件事：人会写错删除语句，所以才有事务、权限、快照和备份。编码智能体并没有改变这条旧规律，只是把犯错速度提高了。

“人非圣贤，孰能无过。”工程系统真正该做的，从来不是期待操作者永不出错，而是让一次错误停在可控范围内。

如果你正在使用 Codex 或同类编码智能体，眼下更实际的做法是：

• **收回默认完全访问.** 只开放当前项目需要的目录和命令，临时提权，用完即收。
• **把任务放进沙箱.** 优先使用隔离工作区、容器或可丢弃环境，不要直接拿真实主目录做试验场。
• **保留命令审查.** 递归删除、修改环境变量、跨出仓库目录等操作，应当要求人工确认或策略拦截。
• **给删除操作加保护.** 团队可以禁止智能体写入主目录和密钥目录，或把删除改成隔离、回收站和延迟清理。
• **准备可验证的恢复路径.** Git、磁盘快照和版本化备份各管一部分，备份存在还不够，还要确认真的能恢复。

如果已经出现异常删除，应立即停止智能体和其他磁盘写入，保留运行日志，不要反复执行同一任务。随后优先从快照或备份恢复；没有备份时，继续写盘可能降低专业数据恢复的成功机会。

这些措施会牺牲一点便利。命令多一次确认，容器多一层配置，权限申请也会拖慢几分钟。反方意见并不难理解：智能体被管得太严，自动化价值会打折。

但这笔账不能只算执行速度。权限越大，错误成本越高。好的产品应当让常规任务在低权限下顺畅完成，把高风险操作单独提出来，而不是让用户在“完全放权”和“几乎不能用”之间二选一。

接下来真正该观察的，也不是模型会不会承诺“更谨慎”。更有价值的变量是：完全访问是否容易被误开，高风险删除能否默认拦截，沙箱和自动审查是否默认启用，以及事故后有没有可靠的恢复机制。

编码智能体正在从“给建议的软件”变成“替人动手的软件”。能力跨过这条线，安全标准也必须跟着跨过去。否则，模型看着越来越强，产品却仍把最昂贵的错误留给用户买单。