Codex 提示网络权限被撤销，新任务启动不了怎么办？

Codex 出现 Fatal error: application network permission was revoked 时，先确认它发生在任务启动前，还是某次网站或应用操作之后。 新任务连第一条回复都没有，与任务已经运行、但某个网站访问被拒绝，需要走不同的排查路径。保存原始报错和未发送内容，再用一条无外部操作的请求对比新旧任务，不要先反复改权限。

截至 2026 年 10 月 21 日，本文核对的资料没有确立通用修复办法。这是一篇针对 Codex 与 ChatGPT Work 桌面体验的诊断指南，不用于绕过明确的网络限制，也不处理自建 Computer Use API。我们查阅了官方文档和公开故障报告，未独立复现 Windows 故障，也未验证某个版本已经修好。

公开报告中的故障是什么样的

在 OpenAI 仓库的 issue #54726 中，Windows 用户报告升级到桌面版 26.1013.3656.0 后出现这条错误。新建 Work 或 Codex 对话，即使只发一句问候，也会反复重连。报告同时说明，普通聊天、浏览器中的聊天或 Work，以及已有的 Work 对话仍能回复。这只是该用户在当时环境下的观察，不代表所有账户都有相同行为。

另一份 issue #54495 描述了桌面版 26.1007.71326 逐渐变慢或无响应，并提到较早的一次对话出现相同错误。报告者明确表示，不能确认这条错误是否解释后续延迟；换对话、重启应用和重启电脑都没有带来持久恢复。

核对时两份报告仍为 open。自动化工具提示它们可能重复，不等于维护者确认了同一根因。它们支持我们检查任务启动过程，但不能证明 VPN、DNS、订阅档位或浏览器扩展是故障原因。

先保留故障，再尝试恢复

把尚未发送的内容复制到本地笔记。记录“关于”界面的应用版本、操作系统、任务模式、所选工作区，以及带时区的发生时间。保存完整错误，不要只写“网络有问题”。同时观察消息是否进入对话记录、是否开始回复、此前是否已经执行过工具。

如果原请求会发送消息、保存文件或提交表单，这一步尤其重要。没有收到回复，不代表操作没有发生。重试前先检查目标位置的实际状态。诊断时改用下面这条纯文本请求：

只回复 OK。不要使用工具，不要浏览网页、读取文件、修改设置，
也不要向本次对话之外发送任何内容。

它只验证基本的消息提交和回复，不验证浏览器控制、文件权限或完整业务流程。分开测试，才能知道到底哪一步恢复了。

用同一条小请求，对比四条路径

只在你原本就有权访问的环境里测试。不要为了让结果一致而新建账户、切换组织或关闭限制。

1. 如果安全，在受影响任务里提交一次上述请求，记录结果，不连续点击发送。
2. 在相同模式、相同工作区新建一个任务，使用同一请求。
3. 如果该工作区有可用的旧任务，在不恢复未完成外部操作的前提下测试它。
4. 如果你已经可以使用普通聊天或浏览器版本，单独测试同一条请求，并明确记录这是另一种环境。

可以直接复制这张表做记录：

如果只有新任务失败，报告这个具体差异。如果所有路径都失败，这组对照还不能定位为任务启动问题，需要检查正常的服务和网络情况，并保留各自的错误。如果任务已经开始、只是某个网站无法访问，应转到 Computer Use 授权后仍不能使用的排查指南，不要套用启动失败的结论。

根据证据检查对应的权限

官方 Computer Use 文档 区分操作系统权限和目标应用的操作授权。在 macOS 上，录屏和辅助功能涉及查看及操作原生应用。对于 Windows 上连一句文字问候都无法回复的新任务，反复切换这些权限并不是已证实的修复方法。

管理配置文档 也区分受策略控制的功能和网络规则。如果设备或工作区受组织管理，向管理员提供准确时间和目标，确认相关操作是否被有意限制。本地允许设置不能放宽管理员的明确拒绝。

个人设备则检查当前版本正常设置界面中实际存在的选项。如果控件不可用或有说明文字，记录原样；不要仅凭缺少一个开关就判断需要升级付费套餐。也不要复制其他用户的内部权限文件。相同的表面错误可能出现在不同的策略或会话状态下。

浏览器连接正常是有用的对照证据，但既不能替代桌面任务的验证，也不授予另一条操作路径权限。反过来，如果某网站被明确拒绝访问，也不应换工具执行同一被拒绝操作。

做一次有边界的恢复测试

保存工作与证据后，完整退出并重新打开桌面应用。先在原本要使用的工作区测试同一条无外部操作的请求，再对比新任务。记录恢复是否能延续到下一次任务，不能把一次成功回复当作永久修复。

通过应用的正常更新机制检查更新。如果确实提供了更新并完成安装，记录更新前后版本，再跑同一组对照。这是合理的恢复检查，不代表本文确认了某个当前版本能修复上述报告。不要安装非官方来源的旧版本，也不要同时修改多个设置。

如果出现登录或工作区的新错误，改按那个错误处理。工作区设置加载失败指南 处理设置请求问题；已经开始回复、随后断开的情况，则参看 流式连接中断排查。保留前后两条错误，新提示可能帮助确定故障进入了哪个阶段。

做完一次可对照的重启或更新检查后，如果相同错误再次出现，就停止反复重置。本文没有证据支持连续重装、删除配置目录、修改应用审批记录或关闭安全控制可以解决它。第二份公开报告也说明，反复重启可能消耗时间，却没有带来持久恢复。

把有用的差异交给支持人员

使用当前版本提供的正常反馈或支持入口。私人标识应通过适当的私密支持渠道提供，不要直接发到公开 issue。下面的模板足够描述关键问题：

应用版本与 build：
操作系统：
发生时间与时区：
任务模式与工作区类型：个人／受管理，不填写私人工作区名称
完整错误：Fatal error: application network permission was revoked
失败阶段：首条回复前／开始回复后／工具操作后
新任务结果：
旧任务结果：
普通聊天或浏览器结果：
重启结果，以及是否复发：
若更新过，更新前后版本：
是否确认存在管理员有意设置的限制：
可提供的脱敏截图或短日志：

公开分享前，移除 API Key、Cookie、授权请求头、私人文件路径和无关聊天内容。保留错误名称、应用版本、时间和事件顺序，这些信息能帮助区分任务初始化故障与一般延迟。

眼前任务恢复的标准是：原本要使用的任务模式能接受一条新的无外部操作消息，并完成回复。若工作需要 Computer Use，再单独验证一次已授权的只读工具操作。普通聊天能回复，不等于工具也恢复了；第二步失败时，保留独立结果，转到对应的权限或连接排查。