Codex 显示超时，并不等于“OpenAI 连不上”，也不等于“账号没额度”。它可能卡在客户端连接、IDE 扩展初始化、MCP 服务启动、某个工具执行、子进程退出，或一个长任务迟迟没有新进展。界面上都像“等了很久”，真正该检查的对象却完全不同。
先不要连续开多个会话，也不要同时退出账号、切模型、换网络、关工具和重写配置。确认当前进程是否仍在运行，查看仓库里已经产生的改动；记下完整错误、时间和时区、使用的 Codex 入口、最后一个完成动作。分享记录前删掉 token、邮箱、私有提示词、源码和完整项目标识。
接下来只问一个问题：计时结束前，Codex 正在等谁？
用最后一个可见动作定位
不要先根据“timeout”猜原因，先找最后一个确实发生的状态。
| 最后可见状态 | 优先检查的边界 | 第一次小检查 |
|---|---|---|
| 桌面端、CLI 或扩展一直未就绪 | 客户端初始化、认证或连接 | 保持同一账号和项目，只做一次干净启动 |
| 一直 Connecting 或反复重连 | 系统网络、代理/VPN、远程主机网络或服务路由 | 在同一入口复现一次，不用浏览器能开网页代替验证 |
| MCP 在启动阶段超时 | 本地命令、环境变量或远程 MCP 地址 | 先运行 codex mcp list，再检查该服务的命令或 URL |
| 只有某个 MCP 工具超时 | 工具下游服务、输入规模或工具自身挂起 | 用同一服务执行最小只读调用 |
| Shell 命令迟迟不退出 | watcher、交互输入、子进程或清理逻辑 | 在相同目录和环境中单独观察该命令 |
| 任务显示运行但没有新进展 | 模型请求、工具循环、批准等待、上下文或界面状态 | 先看会话状态和最后一条动作，再决定是否恢复 |
| 明确出现 HTTP 429 | 用量窗口、API 项目、workspace 或第三方网关限制 | 转到 Codex 429 限流排查 |
中国开发环境还要多区分一层：桌面 App 读取的系统网络、终端继承的代理环境变量、VS Code Remote SSH 实际运行的远程主机、容器内的 DNS/网络，可能不是同一条路径。Chrome 能打开页面，只能证明 Chrome 的路线可用，不能证明 MCP 子进程或远程 Linux 主机也走这条路线。
OpenAI 的沙箱说明把批准策略与文件/网络边界分开：是否弹出批准，和子命令是否拥有目标网络访问，是两个问题。因此，“没有弹框”不能直接解释为权限正常或网络正常。
留一份能比较的现场记录
记录不需要很长，但要能与下一次尝试对比：
- 入口：ChatGPT 桌面端、Codex CLI、IDE 扩展、cloud 或 Remote；
- 客户端版本、操作系统，以及本地/WSL/容器/Remote SSH 环境；
- 登录路线：ChatGPT、OpenAI API key 或自定义 provider，只写类型，不写密钥；
- 完整错误、时间、request/session ID（如果界面提供）；
- 最后正在运行的 MCP 服务、工具或 shell 命令；
- 哪些文件已经变化，后台进程是否仍活着；
- 只保留与本次边界相关的一项配置，不要整份粘贴。
官方开发者命令文档把几个检查分得很清楚：/status 用于查看当前会话配置和 token/context 状态；/debug-config 用于查看实际生效的配置层与策略来源；codex login status 用于确认认证方式。它们都不是通用网络测试，也不能互相替代。若安装版本没有某条命令，以本机 codex --help 和当前界面为准。
MCP 有两个不同的超时
Codex host 上配置的 MCP，把“服务能不能启动”和“某个工具能不能及时完成”分开处理：
toml[mcp_servers.example] command = "example-mcp" startup_timeout_sec = 20 tool_timeout_sec = 90
OpenAI 的 MCP 文档说明，startup_timeout_sec 的默认值是 10 秒，负责服务启动；tool_timeout_sec 的默认值是 60 秒，负责一次工具调用。前者失败时，应先查可执行文件、工作环境、必要变量、远程 URL 与认证；后者失败时，应缩小输入并查工具自身日志、下游服务和 request ID。
只有在同一操作能够正确完成、只是稳定地比当前边界慢一点时，增加超时才是有意义的验证。服务根本不可达、认证错误、进程崩溃或死锁时，把 60 改成 600 只会让失败来得更晚。
本地 STDIO MCP 还可能等待交互输入，或者在启动后立即退出；远程 HTTP MCP 则可能是 URL、token 来源或网络路径问题。桌面端、CLI 和 IDE 在同一 Codex host 上可以共享 MCP 配置，但各自的进程环境、远程宿主和当前界面状态仍可能不同。记录“服务实际跑在哪里”，比笼统写“Codex 连不上”更有用。
子进程不退出，不是连接超时
开发服务器、测试 watcher 和等待 stdin 的脚本本来就可能不自行结束。还有些命令完成主要工作后，因打开的句柄或清理逻辑仍然存活。此时 Codex 与服务端的连接可能完全正常。
在相同工作目录和环境里单独观察命令：
- 它是否持续输出，或已经给出监听地址？
- 它的设计是长期运行，还是应该返回退出码？
- 它是否在等待 Codex 无法提供的交互输入？
长期服务应被明确作为后台进程管理，并用独立的 readiness 检查确认可用；本应退出的命令，则沿自己的日志、子进程树和退出行为排查。不要用更长的 Codex 等待时间掩盖两者差别。
恢复时只改变一个条件
会话还在时，优先恢复而不是盲目复制一个新任务。官方命令参考提供 codex resume，对符合条件的非交互任务也提供 codex exec resume。但恢复上下文不等于外部操作可以安全重复：再次执行写操作前，先查看 Git 变更、云端任务或远程服务是否已经部分完成。
一次有诊断价值的恢复测试应当很小：停止重复后台任务；保持账号、route、模型和项目不变；只修改证据指向的一个条件；运行只读或容易撤销的动作；把新的最后进展位置与原记录比较。
小测试成功后再逐步扩大。若仍停在同一层，带着最小复现以及 request、session、MCP server 或 process ID 升级处理。如果证据最终指向权限、配置优先级或命令网络，转到 Codex 沙箱与 config.toml 指南；如果是 429、credits 或用量窗口，继续走限流 owner。
超时最可靠的修复路径不是“多等一会儿”，而是确认结束的是哪段等待、谁拥有这段等待，再让下一次尝试只回答这一件事。
