Codex超时排障需定位日志目录并分析三类日志：①最近修改的mcp*.log中timed out或connection refused；②codex-tui.log/codex-desktop.log中timeout等关键词；③remote-ssh.log（若使用Remote SSH）。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Codex连接超时后，终端只显示“request timed out”或空白响应，根本看不到底层错误细节——这种黑盒式超时最耽误排障，因为你不知道是网络不通、认证失败，还是服务端根本没收到请求。
确认日志路径并进入目录
先打开终端，执行以下命令定位日志根目录：
【Windows】 cd %USERPROFILE%\.codex\logs\
【macOS/Linux】 cd ~/.codex/logs/
这个目录是Codex所有组件（CLI、Desktop、MCP Server）共用的日志落盘位置。如果该目录不存在，说明日志功能被禁用或配置异常，需先检查config.toml中disable_response_storage = false是否生效。
快速筛选超时相关日志文件
超时问题通常会留下三类日志痕迹，按优先级依次排查：
① 查找最近10分钟内修改的mcp*.log文件——MCP服务超时会在其中记录timed out after 30 seconds或connection refused；
② 检查codex-tui.log（TUI模式）或codex-desktop.log（桌面版），搜索关键词timeout、connect failed、no route to host；
③ 若使用VSCode Remote SSH，必须额外查看remote-ssh.log（若存在），它会暴露Orange Pi等远程设备的真实出网失败点。
实时监控并复现超时过程
方法一：终端中执行
tail -F ~/.codex/logs/mcp*.log 2>/dev/null | grep -i "timeout\|error\|fail"
方法二：在另一终端触发一次超时操作（如运行codex ask "hello"），同时观察上一条命令输出——这样能确保捕获到本次超时的原始日志行，而非历史残留。
【关键提醒】 不要只看最后一行。超时前往往有starting MCP server...或connecting to codex_apps...等前置状态，这些才是定位卡点的真正线索。
从日志里提取有效线索
第一步：找到含timed out after的那行，记下后面紧跟的服务名，例如MCP client for `codex_apps`；
第二步：顺着这行向上翻3～5行，找是否有startup_timeout_sec =配置值，该值决定MCP启动容忍时长；
第三步：若日志中出现Connection refused但没提端口，立刻检查Codex是否正在监听默认端口（如8080），可用netstat -ano | findstr :8080（Windows）或lsof -i :8080（macOS/Linux）验证。
