Codexでタイムアウトが出ても、それだけでOpenAI側の障害、利用上限、ネットワーク不良のどれかに決めることはできません。クライアントが接続する前、IDE拡張の初期化中、MCPサーバーの起動中、ツールの実行中、子プロセスの終了待ち、長いturnの進捗停止は、画面上ではどれも「待ち続けた」に見えるからです。
最初に、すでに生成された変更を守ります。複数の同一タスクを起動せず、ログアウト、モデル変更、ネットワーク変更、MCP無効化、設定の削除を同時に行わないでください。リポジトリの差分と稼働中プロセスを確認し、正確なエラー、時刻とタイムゾーン、Codexのsurfaceとversion、最後に完了した操作、表示されたrequest/session IDを記録します。共有前にtoken、メールアドレス、非公開prompt、ソースコードを除きます。
判断の起点は、タイマーが切れた時に何の完了を待っていたかです。
最後に確認できた進捗から分ける
| 最後の状態 | 調べる境界 | 最初の小さい確認 |
|---|---|---|
| アプリ、CLI、拡張がreadyにならない | client初期化、authentication、connection | 同じaccountとprojectで一度だけclean launch |
| Connectingやstream reconnectが続く | host network、proxy/VPN、remote host、service route | 同じ入口とrouteで一回だけ再現 |
| MCP server startupで止まる | local command、environment、remote MCP URL | codex mcp list後にそのserverだけ確認 |
| 一つのMCP toolがtimeout | tool execution、downstream、入力規模 | 同じtoolの最小read-only call |
| shell commandが終了しない | watcher、stdin待ち、child process、cleanup | 同じdirectory/environmentで直接観察 |
| turnはactiveだが新しい進捗がない | model request、tool loop、approval、context、UI | session stateと最後のactionを確認 |
| HTTP 429が明示される | account/project/workspace/providerのlimit | Codex 429の診断へ |
ブラウザでWebページが開くことは、sandbox内のcommand、IDE extension host、container、WSL、Remote SSH先、MCP processが同じ宛先に到達できる証拠ではありません。OpenAIのSandboxドキュメントでは、approvalとcommandが利用できるfile/network resourceは別の制御です。approvalが表示されなかった事実だけでは、network pathの状態は判定できません。
変更前の状態を短く残す
比較に必要なのは大量のlogではなく、境界が分かる記録です。
- desktop app、CLI、IDE、cloud、remoteのどれか;
- client version、OS、local/worktree/container/WSL/remote host;
- ChatGPT sign-in、direct API key、custom providerのどれか（secretは記録しない）;
- exact error、timestamp、request/session ID;
- 最後のMCP server、tool、shell command;
- 変更済みfileと生きているbackground process;
- 問題に関係するconfig一項目。
公式のDeveloper commandsでは、/statusはsession configurationとtoken/context usage、/debug-configは実際のconfig layerとpolicy source、codex login statusはactive authentication modeを確認するためのものです。いずれも単独ではMCP endpointへの接続テストではありません。インストール版にcommandがなければ、別versionの例を強制せず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のdefaultを10秒、tool_timeout_secを60秒としています。前者はserverの起動、後者は一回のtool実行です。
startupが失敗するなら、executable、environment variable、interactive input、remote URL、authenticationを調べます。一つのtoolだけが遅いなら、入力を最小化し、server log、downstream service、request IDを確認します。待ち時間を延ばす価値があるのは、同じoperationが正しく完了するものの現在の境界を少し超える、と確認できた場合だけです。到達不能、認証失敗、crash、deadlockは長いtimerでは直りません。
local STDIO serverとremote streamable HTTP serverでは残る証拠も異なります。またdesktop app、CLI、IDE extensionは同じCodex host上のMCP configを共有できますが、process environmentやremote hostまで常に同じとは限りません。実際のserver実行場所を記録してください。
子プロセス終了待ちは接続障害ではない
dev server、test watcher、stdin入力を待つscriptは、設計上終了しないことがあります。主要処理が終わっていても、open handleやcleanupがprocessを維持する場合もあります。この時、Codexのconnectionは正常でも待機だけが終わりません。
同じworking directoryとenvironmentでcommandを直接動かし、次を確認します。
- 新しいoutput、またはlistening addressがあるか。
- 自動終了する種類のcommandか。
- Codex runでは渡せないinteractive inputを待っていないか。
long-lived serviceなら意図的にbackgroundで管理し、別のreadiness checkを用意します。本来終了するcommandなら、そのlog、process tree、exit behaviorを調べます。Codex全体のtimeoutを伸ばして両者を混ぜないでください。
Resumeの前に外部の部分完了を確認する
sessionが残っているなら、blind duplicateよりresumeの方が文脈を保ちやすくなります。公式referenceにはinteractive session向けのcodex resumeと、対象になるnon-interactive run向けのcodex exec resumeがあります。ただし会話の復元は、途中の外部writeをもう一度実行して安全という保証ではありません。Git、cloud job、remote serviceを見て、すでに部分完了していないか確認します。
回復テストではaccount、route、model、projectを固定し、証拠が示す一条件だけを変更します。read-onlyまたは容易に戻せる小さな操作を一回だけ行い、最後に進んだ地点を元の記録と比較します。成功したら徐々に広げ、同じ地点で止まればその小さい再現とrequest/session/server/process IDをsupportに渡せます。
結果がpermission、config precedence、command networkを示すならCodex Sandboxとconfig.tomlへ、429やusage windowを示すならlimit側へ進みます。安定した解決は「もっと待つ」ではなく、終わった待機の種類と所有者を特定することです。
