Codex 沙箱、权限与命令审批
Codex 可以执行命令和修改文件，因此权限设置是工作流的一部分，不是安装后可以忽略的选项。沙箱决定命令能接触哪些文件和网络，审批策略决定哪些操作需要你确认。两者共同限制任务的影响范围。
常见沙箱模式
Codex 配置中常见的文件系统模式包括：
| 模式 | 典型用途 | 风险特点 |
|---|---|---|
read-only | 调研、解释、代码审查 | 默认不能修改工作区，适合先分析 |
workspace-write | 日常实现和测试 | 可以修改工作区，项目外写入通常受限 |
danger-full-access | 特殊受控环境 | 限制最少，错误命令影响范围最大 |
多数本地开发任务从 workspace-write 开始更合理。只读审查则用 read-only。不要为了少点几次确认，就把所有任务长期放在完全访问模式中。
审批策略解决什么问题
审批策略控制 Codex 何时暂停并请求授权，例如命令需要突破当前沙箱、访问网络或执行潜在高风险操作。on-request 适合交互式开发：普通的工作区操作可以继续，超出边界时保留人工判断。
审批不是对命令正确性的担保。点击允许前，应检查：
- 命令为什么需要更高权限。
- 目标路径或网络域名是否与任务一致。
- 是否会删除、覆盖、发布或发送数据。
- 能否使用范围更小的命令得到同样结果。
- 是否包含环境变量展开、管道或重定向等不易察觉的副作用。
网络权限和 API 请求
沙箱允许写文件，不代表自动允许访问互联网。安装依赖、读取远程文档、调用外部 API 都可能需要单独的网络权限。使用 APIBest 时，Codex 客户端本身需要能够访问 https://apibest.org/v1；而 Codex 在任务中启动的子命令是否能联网，还取决于当前沙箱网络策略。
这两层容易混淆：模型请求失败通常表现为提供商连接错误；项目命令下载失败则来自执行环境的网络限制。排错时应先判断失败发生在哪一层。
高风险操作的处理方式
以下操作不应仅靠一句模糊提示自动执行：
- 删除大量文件、重置 Git 历史或强制推送。
- 修改生产数据库、云资源或域名配置。
- 读取私钥、浏览器凭据和生产环境变量。
- 发布软件包、部署生产环境或发送外部消息。
- 运行来源不明的安装脚本。
让 Codex 先展示将要执行的准确命令、影响范围和回滚方式，再决定是否批准。对于生产操作，最好让它只生成经过审查的步骤，由受控发布系统执行。
推荐配置思路
个人用户级配置可以保持保守默认值：
approval_policy = "on-request"
sandbox_mode = "workspace-write"项目中的 AGENTS.md 再声明具体限制，例如不执行部署、不接触 .env.production、不修改生成目录。这样个人安全边界和团队工程约定各自负责一层。
权限设置会随 Codex 版本和运行表面变化，完整字段应查看 官方配置参考。遇到失败时，不要立即把权限放到最大；先确认操作是否真的需要更广范围。