error loading configuration: timed out waiting for cloud config bundle after 15s は、Codexが通常のセッションを開始する前に、組織管理の設定を読み込めなかったことを示します。モデルの返答が遅い状態や、MCPツールの実行待ちとは段階が違います。
ただし、この一行だけで原因は決まりません。OpenAI全体の障害、proxy・VPN・firewall、古い認証、選択中のworkspace、キャッシュ、clientの不具合は、どれも候補に残ります。最初から再インストールしたり、.codexやcacheを削除したりすると、比較に必要な状態まで失われます。
安全な進め方は、起動境界を特定し、現在の情報を残し、条件を一つだけ変えて再試行することです。
15秒で待っているもの
OpenAIのManaged configurationでは、対応するChatGPT desktop app、Codex CLI、IDE extensionが、workspaceの管理要件をcloud config bundleとして受け取る仕組みを説明しています。clientやversionによって対応範囲は異なります。
起動時、clientはまず現在のidentityに一致する有効な署名付きcacheを確認します。使えるcacheがなければbundleをretry付きで取得し、検証に成功したものを保存します。取得が失敗またはtimeoutし、有効cacheもない場合は、組織の要件を無視して起動するのではなくエラーを返します。
したがって、表示された15秒から確実に言えるのは次の範囲です。
- 通常のmodel turnより前の設定読み込みで止まった。
- 現在のidentityに使える有効cacheだけでは起動を継続できなかった。
- timeoutは結果であり、service・network・authentication・workspace・clientのどれが原因かは未確定である。
通常のconfig.tomlも同じものではありません。Config precedenceは、CLI override、trusted project、profile、user、systemなどのlocal valueの優先順位です。managed requirementsはworkspaceが許可する範囲を強制する層なので、TOMLを書き換えてもbundleへの到達性は証明できません。
変更する前に残す情報
次の内容があれば、再試行を比較できます。
- exact errorと発生時刻（timezoneを含む）
- desktop app、CLI、IDE extensionのどこで出たか
- Codex version、OS、実際にprocessが動くhost
- 認証方式と選択中のaccount/workspace（tokenやメールアドレスは除く）
- office network、home network、VPN、proxy、Remote SSHなどのroute
- 初回起動、update直後、workspace変更後、再ログイン後のどれか
- 直前まで正常だったversionと時刻
CLIが対応している場合、削除を伴わない確認から始めます。
bashcodex --version codex --help codex doctor --summary codex login status
公式のDeveloper commandsによると、codex doctorはinstallation、configuration、authentication、runtimeなどの状態をまとめます。--jsonはredacted outputとして案内されています。とはいえ、doctorが成功してもremote bundleまで到達した証明にはなりません。
codex login statusもactiveな認証方式を表示するコマンドで、通信テストではありません。installed versionにないcommandは無理に使わず、まずcodex --helpを基準にします。codex logoutは保存済みcredentialsを削除するため、一般的なtimeoutだけを理由に実行しないでください。
共有するlogからはtoken、cookie、メールアドレス、private path、repository名、prompt本文を除きます。home directoryやCodex data directoryを丸ごと渡す必要はありません。
一回の比較で担当領域を絞る
account、workspace、project、client versionを固定し、許可された条件を一つだけ変えます。再試行の時刻、経過時間、同じerrorか別のstageまで進んだかを記録してください。
| 観察 | 一回の比較 | 次に確認する領域 |
|---|---|---|
| OpenAI Statusに関連するactive incidentがある | local dataを消さず、復旧後に同条件で再試行 | service。ただしstatusは集約情報 |
| office networkまたはVPNでだけ失敗する | 規則上許可された別routeで同じhostから一回だけ試す | proxy、firewall、TLS inspection、DNS、egress |
| update直後から始まった | 変更前後のversionを残し、公式に対応するupdateを確認 | client versionまたはpackage |
| account/workspace変更と同時に始まった | 選択中のidentityを確認し、cacheは消さずに再現 | authentication、workspace assignment、policy |
| 同じworkspaceの複数人で同時に起きる | version、地域、時刻をsecretなしで比較 | workspace adminまたはOpenAI support |
| 一人だけ複数の許可済みrouteで再現する | doctor結果と時刻を添えて共有 | account、workspace、client、個別route |
ブラウザでWebページを開けることは、Codex processのrouteが正常という証明になりません。IDE extension host、container、WSL、Remote SSH、corporate VMは、ブラウザと異なるproxy、DNS、CA、egress ruleを使うことがあります。実際にエラーを出したhostで比較します。
組織のsecurity controlを無効化したり、禁止されたnetworkへ切り替えたりしないでください。別routeが許可されない環境では、時刻、host、client、version、routeの種類をnetwork管理者へ渡します。
最初にしないこと
.codex、不明なcache directory、app data全体を削除しないでください。公式説明では、identityが一致する有効cacheはremote取得に失敗した場合でも起動を助ける可能性があります。削除はその証拠と退避経路を同時に失わせます。公開資料も手動cache削除を通常の復旧手順としていません。
MCPのstartup_timeout_secやtool_timeout_secも、このerrorの最初の修正場所ではありません。cloud config bundleは通常セッションより前に読み込まれます。bundleを通過した後にMCPで止まるなら、その新しいstageを別に診断します。
local configを一度に何項目も変更しないでください。明確にprecedenceやsandboxを示す証拠がある場合はCodexのconfig.tomlガイド、refresh tokenの文言が出ている場合は認証更新エラーのガイド、HTTP 429ならrate limitの切り分けが次のownerです。
再ログインを選ぶ条件
再ログインは、login statusが想定外、workspaceが違う、refresh tokenの明示エラーがある、管理者がassignment変更を確認した、など認証を疑う独立した証拠があるときに限ります。先にstatusとdoctorの結果を保存し、ログイン方法を準備してから行います。
症状が15秒timeoutだけなら、logoutは診断ではなく推測です。credentialsを消してしまうため、通信やworkspace policyの問題を認証問題へ置き換えるおそれがあります。
管理者やsupportへ渡す内容
エスカレーションには、exact error、2〜3回のtimestamp、surface、version、OS、実行host、認証方式、account/workspaceの安全な識別、status確認、許可されたnetwork比較、codex doctor --summaryまたはredacted JSONを含めます。最初の発生前に変わったものと、すでに試した操作も短く書きます。
「同じversionとworkspaceで、自宅routeでは通りoffice routeでは止まる」のような比較結果は、「何度も再インストールした」より有用です。次の起動でbundleを通過し、別の場所で止まったなら、15秒errorの推測を持ち越さず、その新しいstageを記録してください。
結論はcacheを消すことでも待ち時間を伸ばすことでもありません。起動時のmanaged configurationという境界を守り、証拠を残し、比較可能な一回のtestで、service・network・version・authentication・workspace policyのどこへ渡すかを決めることです。
