TopsTipOpenAI负责Codex的Thibault Sottiaux表示，团队已经调查了少量GPT-5.6意外删除本地文件的报告。调查发现，这类问题最常出现在Codex获得完全访问权限、未受沙箱保护，同时也没有启用自动审查的环境中。
Sottiaux称，部分事件涉及模型试图修改HOME环境变量，将其指向一个临时目录，但随后发生判断错误，误把用户真正的主目录当作临时目录删除。
OpenAI表示，即使用户主动选择了没有沙箱和审查保护的完全访问模式，这也不是系统应有的行为。公司正在通过更新开发者指令、引导用户选择更安全的权限模式，以及在执行框架中增加额外保护措施来降低风险。
OpenAI尚未公布受影响用户数量、具体客户端版本和完整技术原因。Sottiaux表示，这类事件极为少见，团队将在未来几天发布详细事后分析，进一步说明事故原因和后续改进措施。
什么情况下更容易发生文件误删
根据Sottiaux公布的初步调查，风险主要集中在三个条件同时或先后出现的场景中。
第一，用户启用了完全访问模式。此时Codex可以在没有常规沙箱限制的情况下访问本地文件系统。如果审批策略同时被关闭，模型生成的删除命令可能直接执行，而不会先停下来等待用户确认。
第二，任务没有启用自动审查。Codex的自动审查机制会检查原本需要越过沙箱边界的高风险操作，包括可能造成不可逆损失的破坏性命令。不过，自动审查并不能替代沙箱，而且只有在审批仍然处于交互状态时才会生效。
第三，模型错误修改了HOME环境变量。HOME通常指向macOS或Linux用户的主目录，里面可能包含桌面、文档、下载、配置文件、密钥和应用数据。把它临时改成其他目录会让后续命令产生路径歧义。一旦清理命令错误地解析到真正的主目录，就可能造成大范围文件损失。
这并不意味着GPT-5.6在正常情况下会主动删除用户文件。官方披露指向的是特定权限组合下的错误执行风险：技术边界被移除后，模型的一次路径判断错误可能直接转化为本地文件操作。
沙箱和审批分别保护什么
OpenAI官方文档显示，Codex的本地安全机制主要由沙箱和审批策略两层组成。
沙箱决定模型生成的命令在技术上可以访问哪些文件。默认的workspace-write模式允许Codex读取文件并在当前工作区内修改内容，但不应让它任意写入工作区之外的用户目录。
审批策略决定Codex什么时候必须暂停并请求许可。on-request模式允许常规工作在沙箱内执行，而越过边界的操作需要额外批准。自动审查可以代替用户审核部分审批请求，但不会扩大或缩小原来的沙箱边界。
风险最高的组合是danger-full-access与approval_policy = "never"。OpenAI文档将其称为完全访问：系统不再提供沙箱限制，同时也不会停下来请求批准。
相对更稳妥的本地自动化组合是：
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"
[sandbox_workspace_write]
network_access = false如果当前任务只需要阅读和分析文件，可以进一步使用read-only模式。需要修改项目时再切换到workspace-write，而不是把完全访问设置成长期默认值。
如何防止AI代理删除本地文件
一、不要把完全访问设为默认模式
日常开发优先使用workspace-write与on-request。只有在外部隔离环境、临时虚拟机或可随时重建的容器中，才考虑运行没有沙箱保护的任务。
不要为了减少审批提示而同时关闭沙箱和审批。提示减少的代价，是模型错误命令可能直接作用于整个用户目录。
二、不要修改HOME来创建临时目录
不要要求AI代理通过重设HOME创建临时工作空间，也不要在任务脚本中执行类似“把HOME指向临时文件夹”的操作。
临时文件应使用操作系统提供的临时目录机制，例如macOS和Linux中的mktemp，或由应用程序创建独立、名称明确的临时目录。任务结束时，只清理该次任务创建并经过路径确认的目录。
可以在项目的AGENTS.md中加入长期规则：
禁止修改或覆盖 HOME 环境变量。
禁止递归删除工作区之外的任何路径。
执行删除前必须列出目标路径并请求确认。
临时文件只能放在系统临时目录或项目内明确指定的 tmp 目录。自然语言规则不能替代操作系统沙箱，但可以减少模型主动生成高风险命令的概率。
三、把重要项目纳入版本控制
代码、配置和文档应尽量纳入Git，并在让AI代理执行大规模修改前创建提交或分支。这样即使工作区文件被错误修改或删除，也可以从最近提交恢复。
需要注意的是，Git不能保护尚未提交的文件、被忽略的文件、照片、下载内容和其他个人数据。因此，版本控制只是项目恢复方案，不能代替系统备份。
四、建立独立于电脑的备份
macOS用户可以启用Time Machine，Windows用户可以使用文件历史记录或系统备份，Linux用户可使用快照、增量备份或同步到独立存储设备。
重要资料至少应有一份不受当前AI代理访问权限影响的副本，例如断开连接的移动硬盘、只读快照或带版本历史的云存储。持续连接并允许代理写入的同步目录，不一定能阻止删除操作同步到云端。
五、把个人目录与AI工作区分开
不要直接把整个用户主目录、桌面或文档目录作为Codex工作区。应该为每个项目建立单独目录，只把完成任务所需的文件放入其中。
如果任务需要处理个人资料，可以先复制一份到临时项目目录，让代理操作副本，确认结果后再由用户决定是否覆盖原文件。
六、对删除和批量移动进行人工确认
递归删除、批量重命名、清理缓存、移动主目录文件和修改环境变量，都应被视为高风险操作。
看到删除命令时，不要只检查命令名称，还要检查变量展开后的最终路径。空变量、路径拼接错误、符号链接以及错误的工作目录，都可能让原本针对临时文件的命令作用到其他位置。
七、在隔离环境中运行高风险任务
需要安装未知依赖、执行第三方脚本、批量整理大量文件或进行系统级操作时，优先使用虚拟机、容器、独立测试账号或可丢弃的云端环境。
隔离环境的价值在于，即使代理作出错误判断，影响范围也被限制在可以重新创建的环境中，而不是用户真实的个人目录。
自动审查不能代替备份
自动审查能够识别部分越界和破坏性操作，但它只审查原本会触发审批的请求。已经被当前沙箱允许的命令不会因为开启自动审查而全部重新检查。
因此，可靠的防护不能依赖单一设置，而应形成多层结构：
- 用沙箱限制代理能够写入的范围；
- 用审批或自动审查拦截越界操作；
- 用Git保存项目版本；
- 用系统备份保护未提交文件和个人资料；
- 用隔离环境承载真正需要完全权限的任务。
OpenAI还将发布完整复盘
Sottiaux表示，OpenAI正在更新开发者指令、引导更多用户采用安全权限模式，并为Codex执行框架增加额外防护。团队预计将在未来几天发布更详细的事后分析。
在完整复盘公布前，尚不能确定问题是否只与GPT-5.6的模型行为有关，还是还涉及特定客户端、命令执行框架或环境变量处理逻辑。
目前最直接的应对措施，是检查Codex的权限配置，避免长期使用完全访问和永不审批的组合，同时确认重要本地资料具备可恢复的离线或版本化备份。
资料来源：
