Default、Auto-review、Full access 怎么选？Codex 权限模式实用指南

Codex 不只是聊天工具。它可以读取文件、修改代码、运行命令，甚至访问网络和外部系统。

因此，在开始任务前有一个很现实的问题：这次应该给它多大权限？

权限给得太窄，任务会频繁中断；权限给得太宽，一个错误判断就可能影响项目外文件、凭据或生产环境。

App 里的四种常见选择

Codex App 的权限选择器通常可以看到四类模式：

1. Default permissions；
2. Auto-review；
3. Full access；
4. Custom（使用 config.toml）。

它们并不是模型能力等级，而是“Codex 可以在哪里行动、越界时由谁审批”的不同组合。

Default permissions：日常任务的安全基线

默认权限通常允许 Codex 在当前工作区内读取和修改文件、运行常规本地命令。

当它需要：

• 写入项目外目录；
• 访问网络；
• 调用更敏感的本机能力；
• 获取额外权限；

系统会暂停并请求用户确认。

对应的常见配置可以理解为：

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

它适合修文档、补测试、小范围编码和第一次打开陌生项目。

Auto-review：减少打断，但不拆掉边界

Auto-review 会把一部分越界审批先交给 reviewer agent 判断。

低风险请求可以自动通过，明显危险的请求会被拒绝或继续交给用户确认。

关键点是：Auto-review 不会扩大沙盒。

它只改变“谁来处理审批”，不会自动开放项目外目录，也不会让危险命令绕过安全机制。

常见配置是：

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

它适合步骤较多、偶尔需要联网或调用本机工具，但仍然希望保留安全边界的日常开发。

Full access：只在明确需要时临时开启

Full access 通常意味着：

sandbox_mode = "danger-full-access"
approval_policy = "never"

Codex 不再受本地沙盒限制，也不会弹出审批请求。

这不是“更高效的默认模式”，而是最高风险模式。它可能允许 Codex：

• 写入项目外任意位置；
• 读取更多本机文件；
• 运行系统级命令；
• 访问网络和外部服务；
• 产生难以回滚的副作用。

只有在任务范围非常清楚、环境可以恢复、操作确实无法在工作区权限内完成时，才应临时使用。

支付、权限、生产数据、数据库迁移、发布和凭据处理，不应该仅因为操作麻烦就切到 Full access。

Custom：把长期习惯固化成配置

当你已经知道自己的工作方式，可以使用 config.toml 创建更精细的边界，例如：

• 增加第二个可写工作目录；
• 只允许访问 GitHub 和 npm 域名；
• 默认使用 Auto-review；
• 为危险命令配置“询问”或“禁止”规则；
• 为只读分析、编码和审查创建不同 profile。

Custom 适合稳定工作流，不适合在不了解字段含义时直接复制一份复杂配置。

一张选择表

场景	推荐模式
阅读陌生仓库、做代码审查	只读或 Default
修改文档、测试、小功能	Default
长任务、审批频繁但风险可控	Auto-review
同时操作多个可信项目目录	Custom，扩展 writable roots
系统级调试或特殊本机操作	临时 Full access
数据库迁移、生产发布、支付与权限修改	保留人工审批

权限越高，任务范围越要小

一个很实用的原则是：

权限与任务范围应该反向变化。

如果任务只允许修改两个文件，即使权限较高，影响面也相对清晰；如果任务描述只是“帮我整理电脑”，再高的权限都会放大风险。

在批准高权限前，可以先要求 Codex：

请先说明准备运行的命令、将修改的文件、需要访问的外部资源和可能产生的副作用。暂时不要执行。

写在最后

权限模式不是“越高越好”，而是在效率与风险之间选择合适边界。

对大多数日常任务而言：

Default 起步
→ 审批过多时使用 Auto-review
→ 需要跨目录时配置 Custom
→ Full access 只做临时例外

真正可靠的工作方式，不是让 Codex 什么都能做，而是让它在足够完成任务的最小权限内行动。