Codex 的安全设置有两个独立维度。沙箱决定命令能接触哪些文件和网络，批准策略决定什么时候暂停并请求许可。把两者分开理解，才能知道一次弹窗是在扩大执行范围，还是在确认一条被归为不可信的命令。
本文内容核对到 2026 年 8 月。permission profiles 仍处于 Beta，配置键、默认值和批准入口可能变化，修改前应核对当前官方文档。
先选择沙箱范围
当前 Codex 提供 permission profiles 和旧版 sandbox_mode 两条配置路径。permission profiles 内置 :read-only、:workspace 和 :danger-full-access。旧版机制对应 read-only、workspace-write 和 danger-full-access。日常开发通常从工作区写入开始，排查陌生仓库时可以先用只读范围。
两套机制不能组合。配置里出现 default_permissions 或 [permissions] 时，不要再写 sandbox_mode 和 [sandbox_workspace_write]。任何已加载配置、命令行 --sandbox 或所选 profile 出现 sandbox_mode，Codex 就会使用旧版机制。
版本控制目录启动时，Codex 通常推荐 Auto，它对应工作区写入和按需批准。非版本控制目录通常从只读开始。可以用 /status 查看当前工作区包含哪些目录，不要只凭启动位置猜权限范围。
工作区通常包括当前目录和临时目录。旧版 workspace-write 仍会保护某些路径，不能把“根目录可写”理解成里面每个文件都能任意修改。配置参考提供 writable_roots 增加明确目录，也提供排除 /tmp 和 $TMPDIR 的选项。额外根目录越少，误写到其他项目的机会越低。
再决定什么时候询问
approval_policy 当前支持 untrusted、on-request、never 和 granular 配置。on-request 允许 Codex 在遇到沙箱边界或需要额外许可时提出请求。untrusted 会对不在安全集合内的命令更早询问。never 不会弹出批准请求，适合边界已经由只读沙箱固定的非交互检查，不能拿它替代沙箱。
采用 permission profiles 时，一份保守的开发配置可以这样写。
approval_policy = "on-request"
default_permissions = ":workspace"
已有环境继续使用旧版机制时，可以采用下面这一组。不要再添加 default_permissions 或 [permissions]。
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = false
旧版 workspace-write 下的网络默认关闭。任务确实要下载依赖或访问远端时，可以按单次请求批准，也可以明确把 network_access 改为 true。长期开放以前先确认仓库脚本会访问哪些域名。permission profiles 的网络规则应写在所选 profile 中，不要把两套网络设置混用。
按任务选择组合会更稳。使用 permission profiles 时，只读代码审查可以用 :read-only 加 on-request，需要修改当前仓库时换成 :workspace 加 on-request。无人值守的只读检查可以使用 :read-only 加 never，它遇到越界动作会失败并留下错误，不会等待无人处理的弹窗。继续使用旧版机制的环境，才选对应的 read-only 或 workspace-write。
非交互任务若需要在工作区写构建产物，可以使用 codex exec --sandbox workspace-write。脚本应把失败当失败，不能因为没有用户在场就自动切到全权限。网络、外部写入和凭据访问仍要在运行前固定范围。
看清每一次权限请求
批准前读完整命令、目标路径和理由。写入工作区外、访问网络、运行图形应用和执行高风险 Git 操作，都应当与当前任务直接相关。目标路径含变量、通配符或宽泛目录时，先缩小范围。删除、覆盖、生产发布和外部消息属于另一层授权，沙箱允许执行也不代表用户已经授权业务动作。
approvals_reviewer = "auto_review" 可以把符合条件的批准请求交给审查代理。官方文档明确说明，这个设置不会扩大沙箱，也不会改变已经允许的操作。高风险动作仍要依靠清楚的任务范围和最小权限。
granular 策略还能分别控制 sandbox escalation、rules、MCP elicitation、权限请求和 Skill 脚本批准是否可以弹出。它适合管理员已经知道哪些提示必须由人处理的环境。普通个人项目先用 on-request，等实际提示类型稳定以后再细分，配置会更容易读懂。
CLI 可以临时使用 codex --sandbox read-only --ask-for-approval on-request 启动一次安全检查。官方还提供 codex sandbox macos、linux 和 windows 子命令，用来观察某条命令在沙箱中的表现。--dangerously-bypass-approvals-and-sandbox 会同时跳过沙箱和批准，官方把它标为不推荐的高风险模式。
