Codex 安全与风险边界：什么时候该收紧权限

测试环境：Windows 11 24H2（build 26100）；Codex CLI 0.147.0；2026-08-20 核验。

如果你还不熟悉 Codex 接收任务和执行命令的方式，可以先读《别再把 Codex 当成“会写代码的 ChatGPT”：一文看懂它到底怎么工作》；已经上手的读者直接进入下面的止损步骤即可。

先处理警告，不要和它赌一把

Codex 出现“提示词可能违反使用政策”的错误，或者突然连续弹出异常提醒时，第一反应不该是换一种说法继续轰炸。也不要在警告窗口里急着补充身份证明、公司资料、密钥或完整项目压缩包。警告的成因可能是提示内容、上下文、网络或服务端误判，单凭一条错误信息无法判断是哪一种。

我建议按这个顺序止损：

1. 停止当前会话，不要反复提交同一段被拦截的提示。
2. 如果会话已经混入敏感信息，先记录发生时间和错误原文，再按产品提供的删除入口清理会话；不要为了“证明自己没问题”继续上传更多资料。
3. 检查网络是否稳定，确认没有频繁切换出口、异常代理或共享 IP 的情况。网络检查只能排除一类因素，不能保证解除限制。
4. 重启 Codex，先开一个全新的、内容最小的测试会话。若新会话仍然出现同样的政策错误，停下来走官方支持渠道，不要继续试探边界。

这套处理方法是降低损失的建议，不是“删掉对话就一定解封”的承诺。账号状态、内容审核和风控决定权仍在服务提供方。

两种警告不要混为一谈

“Invalid prompt: your prompt was flagged as potentially violating our usage policy”属于内容或风控层面的拒绝。它不等于 Codex 已经执行了危险命令，也不等于账号一定会被封。新开会话有时能绕开异常上下文，但如果提示本身确实触及限制内容，换会话不能替代修改任务目标。

另一类是执行层警告：Codex 要访问工作区外的文件、联网、删除目录，或者需要提高权限。它关注的是“这一步能不能执行”，不是“这段文字是否违规”。这时要看命令、目标路径和影响范围，不能只看一个醒目的“允许”按钮。

图一　OpenAI 官方文档将沙箱描述为技术边界，将审批描述为越界前的停顿机制。来源：OpenAI Developers，2026-08-21 核验。

新开会话能解决什么

新开会话的价值，是把可能已经污染的上下文清掉。长对话里如果出现了大量网页内容、代码片段、系统错误或被拦截的提示，后续每次重试都可能继续带上同一段上下文。换到一个空会话，用最小化的非敏感任务验证服务是否恢复，这是合理的排查动作。

但新会话不是“绕过审核”的技巧。下面三种情况不能靠换会话解决：

• 原始任务本身就涉及受限制的内容。
• 任务需要上传密钥、身份证明、客户数据等敏感资料。
• 账号或网络出口已经触发服务端风控。

遇到这些情况，继续换标题、拆分提示、反复提交，只会让排查变得更混乱。保留错误原文和时间，停止试探，转到官方支持流程更稳妥。

误删文件的复盘：问题不在临时目录四个字

2026 年 7 月，OpenAI 工程负责人 Thibault Sottiaux 公开回应了少量 GPT-5.6 在 Codex 中意外删除文件的报告。公开转述中反复出现的条件是：运行在 Full access、没有沙箱边界，并且关闭了 Auto-review。最严重的路径错误与 $HOME 有关：模型本想把它改成临时工作目录，却在清理时把真正的 home 目录当成了删除目标。

Codex 创建临时文件夹本身并不能解释这起事故。真正需要追问的是两个失败点：删除前没有再次核对目标；临时路径的变量复用让一个本应短命的目录指向了真实用户目录。只要执行器允许无审批地运行破坏性命令，模型一次路径判断错误就有机会变成真实损失。

OpenAI 后续公开提到的改进方向包括：在删除前核验目标、创建新的临时目录、避免复用系统环境变量、加强对高风险删除命令的审核、让 Full access 更难被误开，并用事故回放和专项评测继续检查。公开表述只到“在回放评测中显著减少”，没有承诺以后绝不发生，转述这起事故时这个限定不能省。

图二　OpenAI Windows Sandbox 文档明确提醒，Full access 可能导致非预期的破坏性操作和数据损失。来源：OpenAI Developers，2026-08-21 核验。

这次修复值得关注的地方，是它没有只给模型补一句“请小心删除”。防线被拆到了几个位置：模型收到的开发者指令、临时目录的创建方式、执行器对删除命令的识别、权限模式的默认入口、Auto-review 的拦截，以及针对真实失败轨迹的回放评测和训练。任何一层都可能失效，所以不能把“模型记住了规则”当成唯一保险。

换句话说，安全边界不只属于模型。执行器要能拒绝越界命令，权限系统要让高风险模式显眼，审核器要能发现破坏性动作，评测要持续复现事故，用户还要保留最后的人工检查点。对 Coding Agent 来说，这些部分合在一起才叫 harness。

图三　Agent harness 将模型指令、执行器、沙箱、审批、自动审核和事故回放等环节串成多层防线。AI 生成/教学示意，不代表 Codex 当前界面。

这次复盘说的是官方层面的事故，日常使用中类似的放手代价我也遇到过，记录在《别一上来就让 Codex 改项目，我已经替你踩过坑了》里，可以对照着看。

现在该怎么保护自己的文件

把下面几件事当成最低限度的工作习惯：

• 重要项目先提交或打包一个可恢复的版本，再让 Agent 改动。
• 真实账号、生产数据库、客户资料和密钥不要放进一次性试验目录。
• 任务只需要改项目文件时，就把工作范围留在项目目录；遇到权限错误，先缩小任务或补充明确的只读路径，不要直接把权限拉满。
• 任何包含递归删除、覆盖、迁移、发布或外发数据的命令，都要人工看完整命令和完整目标路径。
• 测试通过后仍然查看 git diff --stat、git diff 和实际运行过的测试。通过只说明某些检查通过，不说明未覆盖的行为没有变化。

按四个问题判断风险

图四　判断任务前，先看资产、回退能力、验证方式和影响范围。AI 生成/教学示意，不代表 Codex 当前界面。

1. 它会接触什么：示例代码、个人文件、凭据、客户数据，还是生产资源？
2. 能不能回退：有 Git、备份、事务或可丢弃环境吗？
3. 怎么验证：有聚焦测试、构建、预览和人工复核吗？
4. 出错会怎样：影响一个分支，还是会删除、发送、发布或改变云资源？

四个问题里只要有一个答不上来，就把任务降级为只读分析，或先建立隔离环境。风险要结合资产、回退能力和影响范围来判断，红黄绿标签只能做提示。

适合交给 Codex 的任务，也要有边界

代码搜索、只读解释、隔离分支里的小范围修改，以及能运行聚焦测试的修复，通常适合交给 Codex。前提是目标文件明确、变更可回退、结果有人检查。

认证、支付、加密、权限、依赖升级、公共接口、大范围重构、生产 DDL、批量删除和对外发布，都应该保留人工检查点。检查时要看实际差异、命令和目标资源，不能只扫一眼摘要。

如果你还没让 Codex 改过真实项目，可以先从《第一次让 Codex 改项目，我建议你先从这个小任务开始》里的低风险任务练手，再回到上面的边界清单逐条对照。

Mac 内存问题要单独看

不少用户还会遇到另一种烦恼：Codex Desktop 在 Mac 上运行一段时间后占用越来越高。长会话历史、图片附件、本地工具和子进程都可能增加客户端负担，但这和“误删文件”不是同一个安全事件，也不能用一次安全更新推断内存问题已经解决或必然存在。

目前能确认的是，Codex 会在本地保存会话历史，并提供关闭历史持久化、限制历史文件大小等设置。至于某个版本到底是哪一部分占内存，需要在目标机器上看 Activity Monitor，记录会话长度、附件数量、子进程和重启前后的内存曲线。没有这组数据时，最好写成“待实测的稳定性问题”，不要写成官方已经承认的缺陷。

实用的处理方式很朴素：长任务拆成短会话，减少不必要的图片和整仓库上下文，完成一个阶段就关闭闲置线程；如果内存持续上涨，先保存工作结果、退出并重启客户端，再决定是否提交反馈。这样做解决的是资源占用，不是权限风险，两个问题要分开处理。

和下一篇的分工

这篇只回答“为什么要收紧、出现警告怎么止损、哪些动作不能直接放手”。下一篇《权限、沙箱与审批：什么时候放行，什么时候收紧》再回答“权限、沙箱和审批分别控制什么、审批窗口该看哪些字段、如何在可丢弃仓库里验证读写和联网边界”，具体菜单、CLI 参数和 config.toml 的用法也留到那一篇。

资料来源

• 沙箱、权限、审批和 Windows 隔离机制的描述，以 OpenAI 官方文档为准。
• 文件删除案例的 $HOME 细节来自负责人公开表述的媒体转述；原始帖子未能直接核验，以上转述只用于还原事件脉络。
• Mac 客户端内存占用属于用户社区反馈和个人观察，不能与文件删除安全事件混为同一项官方修复；具体内存曲线需要在你自己的版本上实测。

下一篇《权限、沙箱与审批：什么时候放行，什么时候收紧》会把权限、沙箱和审批拆成可操作的配置与检查步骤。