# Codexがcloud config bundleを15秒で読み込めないときの切り分け

> Codex起動時のクラウド設定バンドルのタイムアウトを、安全に切り分ける手順。有効キャッシュを消さず、サービス、経路、version、認証、workspaceを一つずつ確認します。

- Source: https://www.aifreeapi.com/ja/posts/codex-timeout
- Language: ja
- Published: 2026-08-25
- Updated: 2026-08-25
- Publisher: AI Free API (https://www.aifreeapi.com)

`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](https://learn.chatgpt.com/docs/enterprise/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](https://learn.chatgpt.com/docs/config-file/config-basic#configuration-precedence)は、CLI override、trusted project、profile、user、systemなどのlocal valueの優先順位です。managed requirementsはworkspaceが許可する範囲を強制する層なので、TOMLを書き換えてもbundleへの到達性は証明できません。

![起動時にidentityが一致する有効cacheを確認し、なければcloud config bundleを取得し、timeoutかつ有効cacheなしなら停止する分岐](https://www.aifreeapi.com/posts/ja/codex-timeout/img/identity-cache-branch.webp)

## 変更する前に残す情報

次の内容があれば、再試行を比較できます。

- 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が対応している場合、削除を伴わない確認から始めます。

```bash
codex --version
codex --help
codex doctor --summary
codex login status
```

公式の[Developer commands](https://learn.chatgpt.com/docs/developer-commands#codex-doctor)によると、`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](https://status.openai.com/)に関連する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の起動境界、残す情報、一回の比較、避ける操作、管理者やsupportへ渡す内容をまとめた診断マップ](https://www.aifreeapi.com/posts/ja/codex-timeout/img/one-comparison-diagnostic-map.webp)

## 最初にしないこと

`.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ガイド](/ja/posts/codex-config-toml)、refresh tokenの文言が出ている場合は[認証更新エラーのガイド](/ja/posts/codex-access-token-could-not-be-refreshed)、HTTP 429なら[rate limitの切り分け](/ja/posts/codex-rate-limits)が次の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のどこへ渡すかを決めることです。