Codex 跑到一半，屏幕上只剩下 reconnecting，或者等了很久，扔回来一句 command timed out。
人的第一反应通常很直接，重试，换 Key，把 timeout 调大，再不行就重装。
我非常理解这种感觉。一个任务已经跑了十几分钟，谁还有心情研究它到底死在哪一层，先让它活过来再说。
但麻烦也在这里。
网络没连上、模型请求没回来、终端命令没有结束、第三方 Provider 没响应，这四种情况看起来都像卡住了，处理方式却完全不同。混在一起折腾，最常见的结果就是改了一堆配置，问题还在，现场也被自己破坏干净了。。。
这篇文章不提供万能修复按钮。坦率的讲，目前也没有真实超时复现可以支持这种承诺。下面给的是一套待实测的排查路径，核心只有一句话。
先判断，Codex 最后停在哪个动作。
先别改 timeout，先看最后一个可见动作
遇到 codex timeout，先保存四样东西，触发时间、原始命令、最后一条正常输出、完整错误文本。
凭证要脱敏，但不要只截最后那句报错。孤零零一句 timeout，信息量跟一句「坏了」差不多。
可以先确认本机到底在运行哪个版本。
codex --versioncodex --help
2026 年 8 月 25 日的本地只读记录显示，当前环境使用 codex-cli 0.147.0，帮助入口可以正常打开。运行帮助命令时出现过 无法创建 PATH aliases: Operation not permitted 警告，但版本和帮助查询成功。这个警告只能证明别名创建受限，不能直接推断 Codex 的模型请求也坏了。
本地帮助中还能看到 doctor 入口，不过这次没有实际执行，因此也不能写成诊断已经通过。
[真实截图待补：Codex CLI 0.147.0 出现 timeout 或 reconnecting 的完整终端画面，需要同时包含触发命令、系统时间、最后一条可见事件和脱敏后的错误文本]
材料留好之后，只复现一次。
是的，一次。
连续点五次重试看着很努力，但五次请求交叉在一起，反而更难判断谁先出问题。
第一层，连接还没建立
如果任务刚发出去就反复出现 reconnecting，模型还没返回任何内容，工具命令也没有启动，可以先把它当作连接层线索。
注意，是线索，不是结论。
这时先确认故障范围。只有当前 Codex 会话异常，还是其他需要联网的请求也异常。然后换一个已知可用的网络环境，再复现同一条最小请求。不要同时换网络、换账号、换 Key，那样即使恢复了，也不知道究竟是哪一步起作用。
恢复标准也要具体。
同一条最小请求能建立连接，并收到一段完整响应，才能暂时认为连接恢复。偶尔闪过一次成功提示，不算。
如果网络环境正常，Codex 仍持续重连，就先停下来保存现场。别急着重装，重装对于代理、DNS、证书或服务端连接问题未必有帮助，还可能把原来的日志线索一起盖掉。
第二层，连接有了，模型请求还没回来
另一种情况更磨人。
连接看起来已经建立，任务也提交了，但迟迟没有模型回复，工具命令更没有开始。这个时候，问题更接近请求等待或初始化阶段。
先把任务缩到最小。不要拿原来那个需要读几十个文件、跑很多步骤的任务继续试，只发一条不会修改文件的简单请求。最小请求能返回，复杂任务不能返回，说明任务规模、上下文或执行链值得继续拆。最小请求也不返回，则要把注意力放回请求链路和服务状态。
这里最容易踩的坑，是随手加一个网上看到的 timeout 配置。
Codex 的参数和配置会随版本变化。没有在当前版本帮助或官方资料中核对过的字段，不要直接塞进配置文件。一个无效字段可能被忽略，也可能制造新的报错，给排查再加一层雾。
我有时候觉得，故障诊断跟侦探办案特别像。最怕的不是线索少，而是有人一进门就把家具全挪了。
现场很重要。
第三层，模型没卡，是工具命令在跑
有时 Codex 已经完成了判断，也成功启动了工具，只是那个命令自己没有结束。
这和模型请求超时是两件事。
判断它不难，看看最后一个可见动作是不是具体命令。命令有没有持续输出，是否在等待输入，是否访问了不可用资源，或者本来就是一个耗时任务。
可以先把同一条命令拿到独立终端中运行，但不要顺手扩大权限，也不要改业务数据。观察它能否正常结束、退出码是什么、卡住之前输出了什么。
如果命令在独立终端里也卡住，优先处理命令本身。可能是它在等交互输入，也可能是目标服务没有响应。若独立运行很快结束，而 Codex 中持续等待，再记录两边的时间和输出差异。
command timed out 只说明命令没有在限定时间内完成。它不会自动告诉你，根因到底是代码死循环、外部服务缓慢，还是进程在悄悄等你输入。
所以别一上来就把时间拉到无限长。
真正应该问的是，这条命令正常情况下该在多久内出现什么结果。没有成功检查，timeout 再大也只是把失败来得更晚一点。
第四层，Provider 或网关没有给出有效响应
如果你本来就通过正规的第三方 API 路径调用模型，还要再看一层，Provider 或网关。
这时需要把 Codex 终端中的触发时间，与渠道状态、使用记录或请求记录对齐。请求有没有到达，是否留下错误，首包是否异常缓慢，问题集中在一个渠道还是多个渠道，这些才是能继续缩小范围的证据。
这时就可以使用 AI Code With，可以把渠道页和使用记录当作观察入口。已核实的产品事实显示，渠道页提供可用性、缓存复用率、首包延迟 P80、平均花费和模型成本明细，并按优先级选择渠道。当前渠道报错时，系统会尝试下一个可用渠道。
但这块必须把边界说清楚。
自动切换不能绕过认证错误、账户额度问题，也不能保证避开所有上游故障。账户里某一刻看到的延迟或可用性，同样不能当成面向所有用户的性能承诺。AI Code With 在这里的价值，是把原本散落在几处的信息集中起来，方便对时间和请求，不是一块包治百病的护身符。
如果记录里根本没有对应请求，也不要立刻判定 Provider 故障。请求可能压根没走到这一层。
扣回最开始那句话。
看最后一个可见动作。
恢复时一次只动一个变量
排查到这里，真正有效的恢复动作通常很朴素。
连接层就更换一个网络变量，请求层就缩小一次任务，命令层就单独运行那条命令，Provider 层就按同一时间戳核对渠道和使用记录。每次改完，用同一条最小请求验证，不要临时换题。
恢复之后，也别急着宣布彻底解决。
至少记录当前 Codex 版本、操作系统、触发命令、改动项、成功输出和观察时间。如果问题再次出现，这份记录能帮你判断它是偶发波动，还是稳定复现。
下面几种情况，建议停止继续重试。
出现认证或权限错误时，先处理认证和权限。请求可能产生费用却持续没有有效响应时，先停。命令涉及写入、部署或删除操作时，也不要靠反复执行碰运气。还有一种更常见，已经连续改了几个变量，却说不清每次改了什么，那就回到原始现场重新整理证据。
说真的，超时最烦人的地方，并不是等。
是它把很多完全不同的问题，都折叠成了同一个表象。
reconnecting 不是根因，command timed out 也不是答案。它们只是 Codex 在黑箱外面递给你的两张小纸条。
别急着把等待时间拉长。
先看清楚，纸条是从哪一层递出来的。
