很多人刚开始用 Codex CLI，最烦的不是模型不会写代码，而是权限弹窗太多：读文件要不要确认，跑测试要不要确认，装依赖要不要确认，访问网络要不要确认。为了省事直接开 full access，又会把风险一下子放大。
这篇文章不讲“怎么安装 Codex CLI”，而是专门讲一个更容易影响日常效率的问题：Codex CLI 权限怎么设置，才能既让它连续干活，又不把本机和项目完全放开？如果你还没看过基础用法，可以先读 Codex CLI 0.128.0 怎么用，再回来看这篇会更顺。
先分清两个概念：沙箱和审批不是一回事
OpenAI 的 Codex 文档把这件事拆成两层：沙箱决定 Codex 能碰到哪里，审批策略决定什么时候必须停下来问你。也就是说，沙箱是技术边界，审批是交互规则。
你可以把它理解成：
- 沙箱模式：限制命令能读写哪些目录、能不能联网、能不能越过当前工作区。
- 审批策略：当 Codex 想做某件事时，是自动执行、按需询问，还是更频繁地请你确认。
- 审批 reviewer：审批请求由用户自己看，还是交给自动审查流程辅助判断。
这也是为什么有些人明明已经“允许编辑文件”，但 Codex 访问网络或写到工作区外时仍会停下来。它不是坏了，而是越过了当前权限边界。
日常最推荐：workspace-write + on-request
对个人开发者、内容站维护者和小团队来说，最稳的默认组合通常是：
sandbox_mode = "workspace-write"
approval_policy = "on-request"对应命令行思路是：
codex --sandbox workspace-write --ask-for-approval on-request这个组合的好处很明确：Codex 可以在当前项目里读文件、改代码、跑常规本地命令；但当它需要联网、写到工作区外、做更高风险操作时，会停下来让你确认。
如果你经常用 Codex 维护博客、脚本、前端页面或自动化流程，这个模式比“每一步都问”顺滑，也比“完全放开”更适合长期使用。比如老达维护本站时，通常会让 Codex 在项目目录内完成草稿、图片、脚本检查和发布流程，但涉及服务器、凭据、远程操作时必须额外确认。相关的内容运营流程可以参考 AI 自动发布 WordPress 文章怎么做。
三种常见沙箱模式怎么选
read-only：适合审计和方案评估
read-only 适合让 Codex 看代码、解释结构、找问题、做方案，不适合让它直接改。它的优点是风险低，缺点是很容易被审批打断。
适合这些场景：
- 第一次接手陌生仓库，只想让 Codex 读代码和做总结。
- 让 Codex 做代码审查，不希望它自动改文件。
- 项目里有大量敏感配置，暂时不想开放写权限。
workspace-write：适合绝大多数本地开发
workspace-write 是最适合日常 AI 编程的模式。它允许 Codex 在当前工作区内编辑文件和执行常规命令，适合修 bug、补测试、改页面、写脚本、维护文档。
如果你正在比较 Cursor、Claude Code、Codex、Windsurf 这类工具，可以把这篇和 2026 年 AI 编程工具推荐 一起看：工具能力重要，但权限边界决定你能不能放心把任务交给 Agent 连续执行。
danger-full-access：只给隔离环境，不给日常主力机
danger-full-access 会取消沙箱边界。它适合容器、临时虚拟机、CI 测试环境，或者你已经把项目隔离得很干净的场景。
不建议在装着个人资料、浏览器 Cookie、SSH Key、生产配置的主力电脑上长期默认使用。哪怕你信任 Codex，也要考虑依赖脚本、构建命令、第三方包安装过程里的外部风险。
把权限写进 config.toml，而不是每次手动选
如果你希望每次启动 Codex 都使用相同策略，可以把默认配置写到本机的 Codex 配置文件中。一个偏稳妥的个人开发模板可以这样设计：
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"这个配置适合大多数内容站、插件、前端项目、脚本工具项目。它不会完全消除审批，但会把审批集中在真正越界的动作上。
如果你的工作流需要 Codex 同时写多个目录，不要一上来开 full access。更好的做法是明确增加可写根目录，只开放必要范围。比如项目源码在一个目录，生成图片或构建产物在另一个目录，就只把这两个目录加入可写范围。
哪些操作一定要保留人工确认
我不建议把所有审批都关掉，尤其是下面这些操作：
- 读取或改写凭据文件：例如
.env、SSH Key、云服务配置、生产数据库配置。 - 联网下载和执行脚本：例如一行 curl 管道、陌生安装脚本、未锁版本的依赖安装。
- 删除、迁移、覆盖大量文件：尤其是构建目录和内容目录混在一起的项目。
- 操作生产服务：包括远程服务器、WordPress 后台、数据库、对象存储。
- 提交、推送、发布：可以让 Codex 准备，但最终动作最好经过你确认。
如果你正在做 Agent 工作流或自动化发布，可以把权限设计和 AI 智能体与自动化专题 一起看。Agent 真正难的不是“让它做事”，而是把可做、不可做、需要问你的边界提前写清楚。
适合内容站和小团队的权限分层
我更推荐把 Codex 任务分成三层，而不是全都用一个权限模式。
第一层：只读分析
适合 SEO 审计、代码审查、旧文盘点、依赖风险评估。用 read-only 或默认较严格模式，让 Codex 先看清楚项目。
第二层：工作区内自动执行
适合改草稿、修样式、补脚本、跑本地检查。用 workspace-write + on-request，让 Codex 在当前仓库内持续推进。
第三层：高风险操作单独确认
适合发文章、连服务器、改数据库、清理生产文件。即使你用的是 Codex 自动化，也应该把这些动作从普通开发权限里拆出来。本站的实践文章会持续放在 老达 AI 实践专题，后续我也会继续记录哪些自动化适合放开，哪些必须保留人工卡点。
一个实用检查清单
在你把 Codex CLI 交给日常项目之前，建议按这张清单过一遍：
- 项目是否已经放在独立工作区，而不是用户主目录？
.env、密钥、服务器凭据是否有明确规则保护？- 默认是否使用
workspace-write，而不是直接 full access？ - 联网、安装依赖、远程发布是否仍需要审批？
- 是否在
AGENTS.md写清测试、构建、发布和禁止事项？ - 是否能通过 git diff 快速审查 Codex 改了什么？
如果你已经在用 Claude Code，也可以参考 Claude Code Hooks 工作流。两类工具的权限模型不完全相同，但核心思路一致：把重复、低风险的动作自动化，把越界、高风险的动作留给审查。
老达点评
Codex CLI 的权限设置，不是越少审批越高级。真正好用的状态是：它能在一个清楚的工作区里连续完成任务，但一旦要访问网络、碰密钥、越过目录、操作生产环境，就会停下来。
我的建议很简单：日常默认用 workspace-write + on-request，把 full access 留给隔离容器和一次性实验环境。AI 编程工具正在从“代码补全”变成“替你跑完整任务”的 Agent，权限边界会越来越重要。谁先把这套边界设计好，谁就能更放心地把 Codex 用进真实工作流。
