이미지: The Decoder
摘要
- OpenAI修复了Codex中GPT-5.6 Sol未经批准就删除用户真实文件的漏洞。
- 问题原因确认为：一条本应清理临时工作文件夹的指令错误地引用了$HOME等系统变量，结果删除了用户真实的主目录。
- Codex现在会在删除前先验证目标路径，并新增了防止全权限模式被意外开启的安全机制。
- 문제 모델
- GPT-5.6 Sol (코덱스)
- 신고 내용
- 여러 사용자가 자율 실행 중 실제 파일 삭제 보고
- 원인
- 임시 폴더 정리 명령이 $HOME 등 시스템 변수를 잘못 참조
- 조치 1
- 삭제 명령 실행 전 대상 사전 검증
- 조치 2
- 새 임시 폴더 생성, 시스템 변수 오용 차단
- 조치 3
- 위험한 삭제 명령에 대한 검사 강화
- 조치 4
- 전체 접근 모드 우발적 활성화 차단
- 권고
- 샌드박스 모드 사용, 앱 최신 버전 유지
说是要清理临时文件夹，结果主目录没了
在OpenAI的编程智能体Codex中，GPT-5.6 Sol模型在执行任务过程中，未经用户批准就删除了用户的真实文件，这类事故已被多次报告。有用户反映，在让该模型自主执行代码的过程中，文件突然消失。据OpenAI在X上发布的说明，该公司已在本月的安全更新中修复了这一问题。
Codex与ChatGPT、Sora一样，是OpenAI推出的编程智能体，开发者只需下达指令，它就能在真实的计算机环境中编写、运行、修改代码。这次出问题的GPT-5.6 Sol，正是OpenAI在8月10日扩大专属网络安全项目Daybreak时，作为面向防御任务的前沿模型一同发布的模型。一款本应用于漏洞检测和安全代码审查的模型，却引发了删除用户文件的事故，这正是此次修复的背景。
问题出在哪里
问题根源在于一条指令，该指令原本是用来清理代码执行后残留的临时工作文件的。这条指令在指定临时文件夹位置时使用了诸如$HOME这样的系统变量,但在特定情况下，该变量指向的并非临时文件夹，而是用户真实的主目录。由于删除指令直接沿用了这个变量,连本不该被清理的文档、配置文件也一并被删除。此外，Codex在某些情况下可能切换到能够访问整个文件系统的全权限模式，这一点也被指出是扩大受损范围的原因之一。
OpenAI采取的措施
OpenAI已将Codex改为在执行删除指令前先验证目标路径。同时让系统每次都新建临时文件夹，从根本上阻断了系统变量与用户真实目录重叠的情况。风险较高的删除指令需经过更严格的检查，全权限模式的触发条件也被重新设计，以防止被意外开启。OpenAI建议用户保持使用其中一种沙盒模式，并将应用更新至最新版本。
如果你现在正在使用Codex
即便此次修复已经生效，使用Codex时仍有三点值得留意。第一，检查设置，确认运行模式是沙盒模式而非全权限模式。第二，确认应用和CLI工具是否为最新版本。第三，如果要让其托管大规模删除或文件整理工作，最好在执行前单独做好备份。这些措施虽然无法阻止此次漏洞本身，但在类似事故再次发生时，是切实可行的减损办法。
编辑视角
在编程智能体可以直接访问文件系统并执行指令的架构下，一旦让智能体自行判断"该删除什么"，风险便随之产生。这次事故的本质并非模型的推理能力问题，而是执行层的设计缺陷——把$HOME变量当作临时文件夹路径来用的这种代码习惯，本身就是一个即便由人来写也同样危险的模式。不同之处在于，如果是人写的脚本，一次失误也就结束了，而智能体却可能反复重复同样的失误，而且是在未经用户批准的情况下执行的。
对于在实际业务中使用编程智能体的团队而言，这次事故的教训很明确：在授予智能体删除、整理文件的权限时，应把"可访问的路径范围"限制到最小单位。不应授予整个项目文件夹的权限，而应限制在特定子目录内，涉及删除操作的自动化流程最好设置单独的审批环节。OpenAI此次打造的安全机制，说到底也是把这些原则强制嵌入到Codex内部的做法。
随着编程智能体更深入地进入实际运营环境,这类事故只会持续出现。就像OpenAI本周同时公布的Daybreak项目那样，打造专门的安全模型，并细化文件访问权限的做法，预计在未来几个月内不仅会扩展到Codex，还会蔓延至整个竞争性智能体工具领域。
评论