最后核验：2026-11-02
Codex 能改文件却不能下载依赖，或能读代码却不能写入相邻目录，通常需要分别检查文件与网络的沙箱边界、审批触发条件、审批人。先确定卡住的是哪一层，再开放完成当前任务所需的权限。
本指南面向本地 Codex CLI 与桌面应用中的本地开发任务；组织托管策略可能进一步限制可选项。命令与配置依据官方说明整理，未逐项在本站重现实测；下文给出操作后的检查点，不编造执行结果。
三个设置分别管什么
| 设置 | 决定什么 | 不能由它推断的事 |
|---|---|---|
sandbox_mode | 命令能在什么边界内读写、执行 | 工作区可写不代表任意网络请求可用 |
approval_policy | 什么情况下可以请求审批 | never 不会自动解除沙箱 |
approvals_reviewer | 需要审批时由用户还是自动审查处理 | auto_review 不增加目录或网络权限 |
官方本地沙箱模式包括 read-only、workspace-write、danger-full-access。其中 workspace-write 适合常规项目编辑，但项目根下的 .git、.agents、.codex、.aws 等受保护位置仍可能只读。即使文件在项目里，也不能一概认为可写。边界详见沙箱文档。
第一步：只读检查，先把修改范围说清楚
接手陌生仓库，或还不知道报错原因时，可以先以只读模式启动：
codex --sandbox read-only --ask-for-approval on-request
这条命令来自官方的权限配置方式。on-request 允许需要时申请审批，因此只读是起始沙箱边界；获得越界审批后的操作须单独判断。
在交互式 CLI 里用 /status 查看工作区信息，用 /permissions 检查或选择可用权限。确认打开的是实际项目根，而非它的父目录或另一个 worktree。让 Codex 先列出预计修改的文件与验证方法，再决定是否开放编辑。
检查点： 分析阶段没有出现未经你同意的文件修改；建议的路径属于当前项目。如果路径已经错了，先重新打开项目，再调整权限。
第二步：只对当前工作区开放编辑
任务范围确定后，用工作区写入模式开始本地编辑：
codex --sandbox workspace-write --ask-for-approval on-request
先选一个已有的小问题验证，例如改一处文档说明，并要求只修改该文件。完成后查看 diff，再运行与你的改动直接相关的检查。
检查点： 只有指定文件产生预期差异；测试输出能对应到当前改动。如果 Review 面板混入旧修改，切到 Last turn 再对照 Git 状态，具体见Codex 故障排查。
在这个模式下，沙箱命令的网络访问仍可能受限。安装依赖失败时，先判断是联网被拦、仓库地址错误、代理问题，还是依赖本身不存在；有审批请求时核对目的域名与操作，不必因一次下载失败就切换整个会话的访问模式。网页搜索工具与 shell 联网是不同通道，搜索成功不能证明包管理器能联网。
第三步：遇到相邻目录或联网需求，扩大具体边界
假设应用源码和共享包是两个相邻目录，而当前工作区只包含应用。先确认任务确实要改共享包，再考虑把该目录加入允许写入范围（官方配置中的 writable_roots），或者打开覆盖正确项目范围的工作区。不要为路径选错而放开整个文件系统。
被拦操作需要审批时，要核对三个问题：要访问哪个路径或网络目的地、做什么修改、是否仍属于当前任务。依赖安装脚本和它启动的子进程同样受沙箱约束，外层命令被允许不代表任何后续行为都被允许。
如果审批被拒绝，缩小实际操作范围或处理明确缺口。把同一个操作换成脚本、另一种工具或一层包装，并不会让拒绝理由消失；超时也不等于命令已经执行成功。
自动审批怎么开，边界会不会变
需要减少手动审批时，官方提供自动审查。以下是说明性 config.toml 片段，请先检查现有配置，避免重复键或覆盖不相关设置：
approval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "auto_review"
它把需要审批的请求交给自动审查，不是对每个动作重新审批，也不会扩大沙箱。自动审查可能增加用量和耗时，不能保证所有请求都获批。功能是否出现还受客户端、有效配置与组织策略影响，详见自动审批文档。
两个常见误解要分开处理：
approval_policy = "never"表示不请求审批；若仍是workspace-write，无法越界的动作会失败，不会因此获得全盘权限。danger-full-access去掉沙箱边界。它和“由谁审批”是两回事，不应把启用自动审批当成切换到这个模式。
检查点： 自动审批前后，工作区根和允许目录符合你的预期；需要越界时仍出现对应审查结果。不要用真实私密目录或破坏性操作来测试边界。
配置改了却没生效，检查哪里
先检查本次启动参数与已选 profile，再检查受信任项目的 .codex/config.toml、用户配置及管理员管理的配置。官方加载顺序中，CLI 覆盖参数优先于普通配置，但组织 requirements 是强制约束，不能靠本地参数绕过。
未受信任项目的项目级配置可能不会加载；这不代表用户配置也没有加载。桌面应用与 CLI 的显示方式不同，核对时以当前会话的权限和工作区为准，而不是只看磁盘上的某一段 TOML。加载规则见基础配置。
权限调整后，用同一个小任务重新确认路径、diff 和检查结果。若你只需要定位某段代码，回到只读；若还需持续编辑，保留当前任务所需的工作区范围。把可复用的项目操作说明写进AGENTS.md，不在说明文件里保存凭据。
官方来源
- Sandboxing：本地模式、文件系统与网络边界
- Agent approvals and security：审批、交互命令和组织约束
- Auto-review：自动审查配置、限制及拒绝处理
- Configuration basics：配置加载和优先级
核验日期：2026-11-02。本文给出依据官方配置设计的操作顺序，未执行模型任务来实测各权限组合。
