命令被拦、联网失败：读懂 Codex 权限和审批
遇到 permission denied、403 或 network access 报错，按本地、Cloud 与 Legacy 分流，排查权限审批和网络受限，留下可复核记录。
内容核对
适合已经有一次失败记录、但分不清该改目录、检查网络还是处理审批的读者。准备好入口、版本（不可得就注明）、失败动作与脱敏错误。完成后你应拿到一张失败阶段记录卡，能说明下一次只验证什么；没有足够证据时，结论可以是“尚不能定位”。
先分清：哪种工具，在哪执行
| 实际入口 | 首先核对什么 | 容易混淆的地方 |
|---|---|---|
| 本地 / Worktree 的终端命令 | 工作目录、目标文件、实际沙箱与审批限制 | Worktree 仍在本机，隔离 Git 改动不代表放开权限 |
| 当前 Codex Cloud | 所选已发布环境、失败在 setup 还是任务内、目标主机 | 本机文件、登录态与 VPN 不会自动随任务转过去 |
| Codex Cloud (Legacy) | 是否确为 Legacy、setup 与 agent 阶段 | setup 可以联网，不证明默认离线的 agent 阶段可以联网 |
| 浏览器、MCP、连接器 | 失败的具体工具与它显示的访问/审批提示 | 本地命令的网络配置不是这些能力的统一开关 |
依据：运行环境、Permissions 的控制范围、Legacy 网络说明，均核对于 2026-10-19。
ChatGPT Work / Work Cloud 与 Codex Cloud 是不同入口，不能直接套用上表的 Codex 配置步骤。本文下方的 Work 用户反馈也单独标明适用范围。
按失败阶段处理，不凭一个报错猜根因
下面是本站整理的分流方法；错误文本是线索，不是自动诊断规则。
| 你看到的现象 | 先收集的证据 | 下一步 |
|---|---|---|
| 消息发不出、一直重连，尚无命令记录 | 入口、版本、时间、消息是否进入会话 | 按消息送达排查区分客户端连接与任务执行；不要先改项目网络 |
| 等待审批，但找不到可操作控件 | 待批准动作、界面状态、该入口是否支持继续 | 保留现场与任务产物，查同入口的文档或报告；不能把“继续”文本当成已经批准 |
| 找不到文件 | 目标相对路径、仓库与当前目录是否一致 | 先核对目录与文件存在性，不能直接断言缺少权限 |
permission denied / 只读拒绝 |
失败动作、目标路径、现有访问限制、是否为受保护位置 | 区分系统文件权限与沙箱拒绝；仅为任务所需路径提出变更建议 |
network access 被拒绝 / 网络受限 |
失败工具、执行环境、目标主机、明确的策略拒绝信息 | 先查对应环境的有效策略；等待审批与明确不允许是不同状态 |
| DNS、TLS、连接超时 | 原动作、发生时间、错误阶段、代理是否参与 | 在相同环境做获准的最小只读检查；本机浏览器可访问只是另一路径证据 |
HTTP 401 / 403 |
响应来自目标服务还是中间代理、状态与脱敏响应片段 | 检查认证、服务授权或代理策略；仅凭 403 不能判断是 Codex 沙箱拒绝 |
| 推送、发布、发送后中断，结果未知 | 远端提交、部署、消息或资源的只读状态 | 先查是否已经发生，再决定下一步，避免重复写入 |
不要把含 Cookie、Authorization、令牌、签名查询参数的完整日志贴出来。保留本地原始证据，分享时用 <仓库>、<目标主机> 等替代敏感值，并保留错误类型和阶段。
可直接复制的只读排障任务
先只读排查这次失败，不修改权限、配置、凭据或业务文件。
入口与版本：<本地 App / CLI / IDE / 当前 Cloud / Legacy；版本或不可得>
原任务与预期结果：<一句话>
失败动作与时间：<命令或工具名；本地时间与时区>
脱敏错误：<关键错误，删掉密钥、Cookie、个人路径和签名参数>
请先判断：动作未开始、等待审批、执行中失败，还是结果未知。
根据现有证据列出已知、未知和最多两个待验证假设。
如果涉及外部写入，先只读核对是否已经生效，不直接重试。
如果需要新检查，先说明它在哪执行、读哪个目标、预期看到什么；
只执行已获准且不会改变外部状态的最小检查，遇到拒绝就记录并停下该检查。
输出下面的失败阶段记录卡，不把建议操作写成已执行或已修复。
把回答整理成以下产物，便于继续任务或提交问题报告：
入口 / 版本 / 执行环境：
原目标与验收标准：
失败时间与阶段：
动作 / 目标（脱敏）：
实际结果 / 错误 / 已有产物：
已确认的权限或策略证据（没有就写未知）：
尚不能排除的原因：
下一次只改变的一个条件：
预期结果 / 实际结果 / 是否达到原目标：
停止条件与尚未执行项：
证据指向配置时，去对应入口核对
本地命令。 沙箱决定技术上能访问什么，审批策略决定何时询问；--ask-for-approval never 不会自动扩大沙箱。按正在使用的客户端和生效配置核对，不向已有配置粘贴一套“通用全开”设置。参见 Agent approvals & security（2026-10-19 核对）。
当前 Cloud。 如果证据确实指向目标主机未允许，核对环境所需域名及服务认证。获准调整并保存后，在 setup 测试，再 Publish / Republish，并在新任务验收；保存设置不等于现有任务已经采用它。允许主机也不会自动授予目标服务权限。参见 Connect to services（2026-10-19 核对）；完整练习见第 14 章。
Legacy。 使用它自己的环境网络设置与 agent 阶段验收，不照搬当前 Cloud 的页面名称。若不能确认入口，先保留“当前 / Legacy 未确认”，不要猜。
浏览器或连接器。 阅读该工具的实际拒绝原因；终端已放行不代表其他工具已获准。不要通过更换工具绕过明确的访问拒绝。对需要修改访问范围的建议，先写清目标、影响与验证动作，再由有权的人处理。
一个近期反馈，该怎样读
Issue #55123 的作者于 2026-10-18 UTC 报告 macOS Work 卡在等待审批、缺少可用控件。它是 Work 入口的用户报告，不能推断所有 Codex CLI 或 Cloud 都有同样故障。本站于 10-19 核对原帖与后续回复；作者报告重启应用并从 Work 直接新建会话后，新任务可继续，同时改变了两个条件。这不能证明根因，也不证明旧任务已恢复。
这类反馈值得借鉴的是记录入口、阶段和新旧会话结果。本文没有把作者的尝试推荐为通用修复，也没有在本站复现该故障。
怎样验收，怎样判断还没解决
- 记录卡能指出失败发生在哪一步；未知项明确保留，不用推测填满。
- 每次只改变一个与证据有关的条件；改变前后比较同一目标、同一操作和同一执行环境。
- “不再弹窗”“命令返回 0”只证明该步骤的结果；仍须检查原本要完成的文件、测试、服务响应或远端状态。
- 若仍失败，记录新的错误阶段与已执行项，保留工作区产物，不反复扩大权限。
- 文档核对、页面检索通过、客户端故障恢复与读者收益分开记录。本文交付前两者，后两者尚未验证。
继续阅读：任务执行与验证闭环、CLI 常用选项、说完成了但结果不能用。