适合谁读：已经让 Codex 修改代码、运行测试或处理发布任务，却不确定“它能访问哪里、什么时候会问我”的开发者。核心结论是：沙箱和审批不是同一个开关；前者限制技术能力，后者规定何时暂停确认。最稳妥的日常组合，是工作区可写、网络默认关闭、越界动作按需审批。
本文更新：2026 年 8 月 4 日。文中行为与配置依据当日 OpenAI 官方文档整理。不同 Codex 客户端、组织策略和受管设备可能有额外限制，应以当前任务显示的权限状态为准。
先分清两个容易混淆的概念¶ ↑
Codex 的安全边界由两层共同组成。
第一层是 sandbox mode（沙箱模式），它决定命令在技术上能够访问什么，例如哪些目录可写、能否访问网络。第二层是 approval policy（审批策略），它决定遇到越界、联网或不受信任命令时，是暂停询问、直接拒绝，还是在既定范围内继续。
这意味着“从不弹审批”不等于“拥有全部权限”。如果沙箱是只读，即使审批策略设为 never，Codex 仍只能在只读边界内尽力完成任务。反过来，开放了很大的沙箱范围，也不代表每个高风险动作都应该自动执行。
日常开发优先使用工作区写入¶ ↑
对受版本控制的项目，实用起点是 workspace-write 配合 on-request：Codex 可以读取文件、修改当前工作区并运行常规命令；写入工作区之外或访问网络时，需要额外批准。
一次性的 CLI 启动方式如下：
codex --sandbox workspace-write --ask-for-approval on-request
这套组合适合修复 Bug、补测试、重构和更新文档。它把高频、可回滚的仓库内操作留在自动流程中，同时把跨目录写入、下载依赖或访问外部服务留给人工确认。
开始任务前仍应检查 Git 状态，并明确要求保留无关改动：
git status --short git diff --stat
这些命令只读且容易复核。任务结束时再次执行，可以确认变更是否仍在预期文件范围内。
只分析、不改代码时切到只读¶ ↑
当目标是代码审查、事故诊断、方案设计或理解调用链时，直接使用只读模式更清楚：
codex --sandbox read-only --ask-for-approval on-request
在交互客户端中也可以通过 /permissions 查看或切换权限。只读模式的价值不只是防止误修改，还会让任务契约更明确：先收集证据和提出方案，等确认后再进入实现阶段。
如果任务运行在 CI 中且只需要生成报告，可以组合只读沙箱与 never，避免无人值守流程卡在审批提示上：
codex --sandbox read-only --ask-for-approval never
这里的 never 是“不询问”，不是“自动放行”。超出只读边界的动作不会因此获得权限。
网络权限要单独看待¶ ↑
官方文档说明，本地 Codex 的默认工作区写入模式并不会自动开放命令网络访问。需要联网安装依赖、查询远端 API 或访问包仓库时，Codex 可能发起审批。
长期开放网络之前，先判断任务是否真的需要“所有命令都能联网”。很多场景可以拆开处理：先在受控步骤下载依赖，再离线修改和测试；查询公开资料使用专门的搜索工具，而不是让任意脚本拥有外网能力；访问公司系统时，只开放必要域名和最小权限账户。
如果确实要在个人配置中允许工作区命令联网，官方配置项是：
[sandbox_workspace_write] network_access = true
修改前应保存原配置，任务结束后恢复；团队环境还应优先使用域名级出口规则，而不是把全网访问当成默认值。网页和搜索结果也应视为不可信输入，避免把页面里的提示词当成项目指令执行。
审批时重点看四件事¶ ↑
审批弹窗不是形式确认。每次批准前，至少检查以下四项：
-
目标范围：具体会写哪个目录、访问哪个域名、调用哪个外部系统；
-
命令内容：是否包含递归删除、强制覆盖、上传文件或扩大权限；
-
数据边界：请求是否可能带出令牌、环境变量、源码、日志或用户数据；
-
回滚方式：失败后能否通过 Git Diff、备份或可逆操作恢复。
对“安装依赖”这类常见请求，也要确认锁文件和来源。对数据库写入、生产发布、发送邮件、删除云资源等外部副作用，审批前还应核对环境、对象数量和幂等性。批准的是一个明确动作，不是把后续所有相似操作永久交出去。
不要把 full access 当作省事模式¶ ↑
Codex 提供更开放的 danger-full-access 以及绕过审批与沙箱的选项，但官方明确要求谨慎使用。它们适合隔离良好、可随时销毁的测试环境，而不适合作为个人电脑或日常项目的默认配置。
真实风险往往不是模型“故意破坏”，而是任务描述不完整、脚本目标解析错误、第三方内容带有提示注入，或一条看似普通的命令继承了过大的系统权限。沙箱的作用，就是在这些判断失误发生时缩小损失半径。
如果某个任务频繁需要同一种越界操作，正确方向是缩小并固化权限：增加一个明确的可写目录、允许一个固定命令前缀、开放必要域名，或把高风险步骤封装成可审查脚本，而不是直接取消全部边界。
一套可复用的三档工作流¶ ↑
可以把日常任务分成三档：
-
分析档：
read-only + on-request，用于诊断、审查和方案； -
开发档：
workspace-write + on-request，用于大多数仓库内修改和测试； -
无人值守档：只给确定、可回滚、范围固定的任务使用，优先
read-only + never；需要写入时必须把目录、命令和网络目的地限制清楚。
无论哪一档，都应在提示词中写明目标文件、禁止事项、验证命令和完成标准。权限控制负责“不能越界”，任务说明负责“应该做对什么”，Git Diff 和测试负责“结果是否真的正确”。三者缺一不可。
最小安全检查清单¶ ↑
开始前确认：当前目录正确、无关改动已识别、任务是否需要写入和联网。审批时确认：命令、目标、数据和回滚路径。结束后确认：Git Diff 只包含预期改动、测试通过、没有新增凭据或个人路径、外部副作用已回读验证。
真正高效的 Codex 工作流，不是让所有提示都消失，而是让普通操作顺畅通过，让少数真正改变信任边界的动作停在正确的位置。先用最小权限跑通，再针对反复出现的合法需求精确放宽，通常比一开始追求“完全自动”更快，也更稳定。