很多开发者使用Codex时，主要关注两个问题：
代码写得对不对。
任务完成得快不快。
但Codex与普通聊天工具不同。
它不仅可以分析代码，还可能读取文件、修改目录、运行测试、安装依赖，甚至调用带有外部影响的工具。
因此，在让Codex开始执行任务之前，还有一个更重要的问题：
它可以访问哪些内容，又能自动执行到什么程度？
这就是权限、沙箱和审批策略需要解决的问题。
Plus可以提供Codex使用资格和相应的使用空间，但套餐等级并不等于本地权限等级。即使使用Plus，Codex能够读取什么、修改什么、哪些操作需要询问，仍然取决于当前的沙箱和审批设置。
一、沙箱和审批不是同一个概念
很多人会把“沙箱”和“需要确认”理解成同一项设置。
实际上，它们负责不同问题。
沙箱决定能力边界
也就是Codex在技术上可以：
-
读取哪些文件；
-
修改哪些目录；
-
运行哪些本地命令；
-
是否可以访问网络；
-
是否能够离开当前项目范围。
审批决定何时暂停
审批策略决定Codex在执行某些动作前，是否必须先向用户申请确认。
例如：
-
访问项目外的目录；
-
使用网络；
-
运行高风险命令；
-
调用会产生外部影响的工具。
OpenAI当前将这两层控制分开：沙箱负责限制可访问范围，审批策略负责决定什么时候必须暂停并询问用户。
二、只读模式适合分析和规划
如果当前任务只是：
-
分析代码库；
-
查找问题位置；
-
阅读日志；
-
设计修改方案；
-
评估影响范围；
建议先使用只读模式。
在read-only模式下，Codex可以检查文件，但不能直接修改代码；需要执行写入或受限制命令时，必须先获得许可。
这种模式特别适合任务刚开始、需求还不够明确的时候。
例如，不要一上来就让Codex修复整个支付模块。
可以先要求：
只分析当前支付流程，找出可能导致重复扣款的位置，列出相关文件和修改建议，暂时不要修改代码。
先完成分析，再决定是否开放写入权限，可以减少AI在错误方向上快速执行的风险。
三、日常开发优先使用项目内写入
对于已经明确的普通开发任务，可以使用workspace-write。
在这个模式下，Codex通常可以：
-
读取当前项目文件；
-
修改项目工作区内的代码；
-
运行常规本地命令；
-
执行测试和检查工具。
但它默认不能随意修改项目外的文件，也不会自动获得网络访问。需要离开工作区或访问网络时，通常会触发审批。
它适合：
-
修复明确Bug；
-
修改指定模块；
-
补充单元测试；
-
调整项目配置；
-
执行本地构建和检查。
对大多数日常Codex任务来说，workspace-write加按需审批，是效率与风险之间更合适的平衡。
四、不要轻易开启完全访问
完全访问通常对应danger-full-access。
在这种模式下，Codex不再受到常规文件系统和网络边界限制。如果同时关闭审批，它可以在较少人工干预的情况下执行更广泛的操作。
这并不代表Codex一定会执行危险操作。
但一旦任务理解错误、命令写错或者项目中存在恶意指令，影响范围可能不再局限于当前代码库。
可能涉及：
-
删除项目外文件；
-
修改用户配置；
-
读取无关目录；
-
访问网络资源；
-
运行破坏性命令。
OpenAI也明确提醒，完全访问模式可能导致非预期的破坏性操作和数据丢失，因此不应该作为普通任务的默认选项。
五、审批策略应该怎样选？
Codex目前常见的审批策略包括：
untrusted
对于不在可信范围内的命令，Codex会先询问。
适合：
-
第一次接触的代码库；
-
不熟悉的脚本；
-
来源不明确的项目；
-
安全要求较高的环境。
on-request
Codex可以在沙箱范围内正常执行，需要突破边界时再申请批准。
这是比较适合日常开发的方式。
例如：
-
项目内修改自动执行；
-
访问网络需要批准；
-
修改项目外文件需要批准；
-
高权限命令需要批准。
never
Codex不会停下来显示审批请求。
但这不等于自动拥有完全权限。它仍然可能受到沙箱边界限制，只是遇到无法执行的操作时，不会等待用户批准。
所以：
never代表不询问，不代表没有限制。
真正风险最高的组合，是完全访问与不审批同时开启。
六、哪些操作建议必须人工确认？
即使是在可信项目中，以下操作也建议保留人工审批：
-
删除大量文件；
-
修改项目外目录；
-
安装或升级生产依赖；
-
修改数据库结构；
-
执行数据迁移；
-
访问生产环境；
-
修改系统配置；
-
使用密钥和敏感凭证；
-
开启不受限制的网络访问；
-
执行无法回退的命令。
这些操作一旦出错，影响往往超过当前代码修改本身。
程序员不需要确认每一次普通测试。
但必须控制那些会改变系统边界、数据状态和外部环境的操作。
七、网络访问为什么要单独控制？
Codex本地运行时，默认通常关闭命令网络访问。只有明确配置后，项目中的脚本和子进程才能连接外部网络。
关闭网络可以降低：
-
项目文件被意外上传；
-
恶意依赖自动下载；
-
外部内容注入任务；
-
脚本连接未知服务；
-
敏感信息被发送出去。
但有些任务确实需要网络，例如：
-
安装依赖；
-
查询软件包；
-
调用测试接口；
-
获取远程文档。
更稳妥的做法不是直接开放所有网络，而是只为当前任务开放必要访问范围。
能使用域名限制时，优先只允许指定服务，而不是允许任意外部连接。
八、Windows用户应该注意什么？
在Windows原生环境中，Codex当前优先推荐使用elevated沙箱。
它会通过专用的低权限沙箱用户、文件权限边界和网络规则隔离命令执行。
如果设备权限或企业策略不允许完成设置，可以使用unelevated作为备用方式，但它的隔离能力相对较弱。
对于普通Windows用户，可以遵循：
优先完成推荐沙箱设置；
默认只允许当前项目写入；
不随意打开完全访问；
公司电脑遇到策略限制时，不要强行关闭系统安全措施；
需要额外目录时，只增加具体目录，不扩大整个磁盘权限。
九、不同任务应该怎样设置？
代码分析任务
推荐：
只读模式＋人工审批
适合先理解项目，不进行修改。
普通Bug修复
推荐：
项目内写入＋按需审批
允许修改当前仓库和运行测试，但不自动突破项目边界。
安装依赖任务
推荐：
项目内写入＋网络访问单独批准
先确认依赖来源、版本和修改内容。
数据库或生产任务
推荐：
严格沙箱＋所有高风险操作人工确认
不要把生产环境操作直接交给Codex自动完成。
自动化批量任务
推荐：
独立项目或worktree＋明确写入目录＋可回退检查点
不要为了让任务顺利执行，就直接开放整台电脑权限。
十、推荐的Codex权限流程
一个更稳妥的执行顺序是：
第一步：只读分析
↓
第二步：确认修改计划
↓
第三步：开放项目内写入
↓
第四步：自动运行常规测试
↓
第五步：网络和项目外操作单独审批
↓
第六步：人工检查代码差异
↓
第七步：决定是否合并
权限应该随着任务逐步开放。
而不是在任务开始前一次性全部交给AI。
结语
ChatGPT可以帮助开发者分析任务、判断风险和制定执行边界。
Codex可以在沙箱范围内读取项目、修改代码和运行测试。
Plus能够支撑更频繁的日常协作。
但AI执行能力越强，权限设计就越重要。
更安全的原则不是完全禁止Codex执行操作。
而是：
只给完成当前任务真正需要的权限。
普通操作允许自动完成。
高风险操作必须暂停确认。
任务结束后及时收回临时权限。
不要用完全访问来换取表面上的方便。
稳定的AI开发流程，应该让Codex能高效工作，同时始终知道边界在哪里。
