Codexで作業が止まったときに出るエラーを、意味と対処の順にまとめました。
載せた文面は、当方のパソコンの Codex（デスクトップアプリとコマンド版）の記録に実際に残っていたものと、試しに起こしたものです。
フォルダ名やIDなど、個人を特定できる部分は伏せています。
対処の前後で、発生日時・アプリかCLIか・版・エラー全文・完了済みの操作を手元に記録します。
設定は一度に1項目だけ変え、同じ操作でエラーが消えるかを確認してください。
| エラー | 意味 | まずやること |
|---|---|---|
| stream disconnected | 通信が途中で切れた | 再試行を待つ。失敗後は実行済みの操作とネットワークを確認 |
| You’ve hit your usage limit | プランの使用量を使い切った | 使用量画面の再開日時・追加利用の適用条件を確認 |
| Failed to refresh token: 401 | ログインが切れた | ログインし直す |
| Error loading configuration | config.toml の書き方か値がおかしい | 表示された行を直すか、Codexを新しくする |
| アクセスが拒否されました | 書き込み権限などの不足 | 対象パス・OSの権限・サンドボックスを確認 |
| リモート サーバーに接続できません | 接続先との通信に失敗 | 接続先・ネットワーク・実行環境の制限を確認 |
| failed to refresh available models | モデルの一覧を取れなかった | モデルを選べるか・作業が続くか確認 |
| ログインし直しても401が続く／設定を直してもエラーが消えない | 認証方法・設定・管理ポリシーなどを要確認 | ログとエラー位置を確認し、該当箇所だけ対処 |
掲載ログは従来のWindows環境での記録です。
2026年10月23日に認証・設定・Windowsサンドボックス・エラーコードの公式資料を再照合しました。
今回は同じ障害を発生させる再現試験はしていません。
stream disconnected
stream disconnected - retrying sampling request (5/5 in 3.203s)... retries=5 max_retries=5 sampling_error=stream disconnected before completion: IO error: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。
(os error 10053)
応答の受信が完了する前に通信が切れたことを示します。
接続先やネットワーク経路は使用中のモデル提供元・プロキシ設定によって異なります。この行は切断後に5回目の再試行を予定している記録です。
この1行だけでは、5回目の成否や最終的な復旧は分かりません。
再試行回数は使用中の版や設定によって変わります。
当方の記録には、このやり直しの行が数日にわたって何度も残っていました。
- 自動再試行が終わるまで待つ。失敗した場合は、ファイル変更・送信・公開など既に完了した操作を確認し、未完部分だけ再開する
- VPN・プロキシ・セキュリティソフトが通信を切っていないかを見る
- Wi-Fiが不安定なら、有線にするか場所を変える
Windowsの10053はホスト側での接続中断を示し、タイムアウトやプロトコルエラーでも発生します。
特定のセキュリティソフトが原因とは断定できません。
You've hit your usage limit
You’ve hit your usage limit. Visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at Sep 25th, 2026 11:26 AM.ChatGPTのプランに含まれる Codex の使用量を使い切ったときに出ます。
文面に、使えるようになる日時が書かれています。
- 表示された日時まで待つ
- 急ぐ場合は使用量画面で、購入・リセットなど利用可能な選択肢と適用対象を確認する
- 残りの量は、ChatGPTの Codex の使用量の画面で確かめる
制限がリセットされる仕組みは、Codexの利用制限リセットまとめで詳しく紹介しています。
Failed to refresh token: 401
Failed to refresh token: 401 Unauthorized: {
"error": {
"message": "Your session has ended. Please log in again.",
"type": "invalid_request_error",
"param": null,
"code": "refresh_token_invalidated"
}
}ログインの有効期限を延ばそうとして、失敗したときに出ます。
掲載例の refresh_token_invalidated は、認証の更新に使うトークンが無効になったことを示します。
この文面だけでは、無効になったきっかけまでは断定できません。
ChatGPTでログインしているCLIでは、次のように再ログインし、その後 codex login status で状態を確認します。
再発する場合は、下の診断手順に進みます。
codex logout
codex loginブラウザが開かない・認証が戻ってこないとき
codex login はブラウザーを開いて認証します。
SSH先やコンテナでは、ブラウザーの認証結果がCLIへ戻らず止まることがあります。
公式ドキュメントではデバイスコードでのログインが案内されています。
先に個人アカウントのセキュリティ設定、または管理者によるワークスペースの権限設定で有効にする必要があります。
利用できない場合は、SSHのポート転送など公式の代替手順を確認します。
codex login --device-auth別の端末でリンクを開き、表示された一度きりのコードを入れると認証できます。
対話式のログイン画面からも「Sign in with Device Code」を選べます。
いまログインできているかどうかは、次のコマンドで確かめられます。
codex login statusログインに失敗したときは、ログの場所のcodex-login.logにあるエラー内容を手掛かりに調べます。
ログインのやり直し方とつまずきやすい点は、Codexにログインできないときの対処法で紹介しています。
Error loading configuration
Error loading configuration: C:\Users\（ユーザー名）\.codex\config.toml:6:16: unknown variant `default`, expected `fast` or `flex`config.toml に、Codexが知らない値や書き方の誤りがあると出ます。
設定読込みが失敗すると、ログイン確認などが認証処理の前に停止する場合があります。
ヘルプまで含めてすべての操作が停止するとは限りません。
ファイル名のあとの 6:16 は、6行目の16文字目という意味です。
この例は、新しいデスクトップアプリが書いた値を古いコマンド版が知らなかったもので、コマンド版を新しくすると直りました。
config.toml の書き方は、Codexのconfig.tomlの場所と書き方で紹介しています。
サンドボックスで止められたとき
サンドボックスを有効にしたCodexでは、コマンドのファイル・ネットワークアクセスを制限します。
許可範囲は実行モードや管理者ポリシーで変わります。
書き込みが止められた（read-only）
読み取り専用（read-only）のサンドボックスでファイルを作らせたところ、Windowsでは次のエラーになりました。
Set-Content : パス 'C:\demo\codex-demo\test.txt' へのアクセスが拒否されました。
+ CategoryInfo : PermissionDenied: (C:\demo\codex-demo\test.txt:String) [Set-Content], UnauthorizedAccessこのエラー文だけでサンドボックスが原因とは限りません。
対象パスとOSの書き込み権限を確認し、CLIの/statusで作業場所と許可範囲を確かめます。read-only が原因で、作業フォルダー内の編集を許可したい場合に workspace-write を使います。保護された設定フォルダーなどは、このモードでも書き込めないことがあります。codex -s workspace-writeネットにつながらない
workspace-writeのサンドボックスは、初期状態ではネットを使えません。Invoke-WebRequest : リモート サーバーに接続できません。接続先の停止、DNS、プロキシ、証明書でも同じように接続に失敗します。
まず接続先URLとエラー全文を確認してください。サンドボックス内のコマンドだけがネット制限で失敗し、その通信を許可してよい場合は、config.toml に次の設定を使います。[sandbox_workspace_write] network_access = trueこの設定は
sandbox_mode = "workspace-write"のときに効きます。書き込める場所を足したいときは、同じ表に
writable_rootsを並べます。次のパスはLinuxなどの例なので、自分が追加を許可する既存フォルダーの絶対パスに置き換えます。
Windowsなら、たとえば
writable_roots = ["C:/demo/projects"]のように指定し、既にある[sandbox_workspace_write]へ項目を追記してください。[sandbox_workspace_write] network_access = true writable_roots = ["/home/user/projects"]全体に書いたのに効かないときは、プロジェクト側で上書きされていないか確かめてください。プロジェクトの設定は信頼済みのプロジェクトで読み込まれ、管理者が強制するネットワーク制限は利用者の設定で上書きできません。
ネットワークを有効にしても接続先が制限される場合は、
/debug-configで有効な設定を確認し、管理者の制限やネットワークプロキシの接続先ルールを照合してください。Windowsのサンドボックスの設定に失敗する
Windowsの実装は一種類ではありません。
公式資料には
mxcと、従来方式のelevated・unelevatedが案内されています。専用ユーザーを作る説明は elevated に当てはまります。
利用できる方式はWindowsの対応状況と組織のポリシーに依存します。
unelevated への切り替えも、組織で許可されている場合に限られます。
サンドボックスのコマンドがエラー1385で失敗するときは、必要なログオン権限をWindowsが拒否しています。
管理者にポリシーを確認し、利用中の方式・Windowsの版・エラー全文を伝えてください。
フォルダーを読めない場合は、CLIの
/status・/debug-configとWindowsのファイル権限を確認します。管理対象の制限は管理者に確認し、原因不明のままサンドボックスを無効にしないでください。
Windowsのサンドボックスを調べるログは
CODEX_HOME/.sandbox/sandbox.logです。問い合わせ時は使用中の実装・Windowsの版・エラー全文を添えますが、
CODEX_HOME/.sandbox-secrets/の内容は送らないでください。failed to refresh available models
failed to refresh available models: request timed out起動時などに、使えるモデルの一覧を取りに行って時間切れになったという記録です。
当方の記録では、いちばん多く残っていたのがこの行でした。
単発の記録でモデルを選べて作業も進むなら、すぐに設定を変更する必要はありません。
繰り返し発生してモデル選択や起動が止まる場合は、通信状況と認証状態を確認します。
記録の見方
設定や記録の既定の基点はホームの.codexです。
CODEX_HOMEやlog_dirで変わるため、実際の保存先を確認してください。
ログインで失敗したときは、ログの場所のcodex-login.logにあるエラー内容を確認します。
サポートに問い合わせるときは、記録にフォルダ名や会話の一部が入っていることがあるので、渡す前に中身を確かめてください。
設定やログインが直らないときの診断順
codex logout→codex loginを繰り返しても401が出続ける、または設定を直したのにError loading configurationが消えない場合は、ホームフォルダーの.codexの中を1つずつ確かめます。いきなりフォルダーごと消すと、設定もログインも一緒に失うため、順番があります。
ファイル・場所 中身 消したときに失うもの ~/.codex/auth.jsonファイル保存を使う場合のログイン情報（アクセストークン） ファイル内の認証情報。OSの資格情報ストアは別 ~/.codex/config.toml自分で書いた設定（モデル、サンドボックス、承認の方針など） このファイルに記載した設定。先に控えを取る ログの場所（ codex-login.logなど）動作とログインの記録 原因を調べる手がかりだけ リポジトリの .codex/config.tomlそのプロジェクトだけの上書き設定 プロジェクト固有の設定。全体の設定を直しても効かない原因になりやすい ファイルの役割はCodex公式ドキュメント「Authentication」「Configuration」による 試す順番は次のとおりです。
- まず控えを取る。
config.tomlを別名でコピーしておく（Windowsのコマンドプロンプトならcopy %USERPROFILE%\.codex\config.toml %USERPROFILE%\config.toml.bak、Mac・Linuxならcp ~/.codex/config.toml ~/config.toml.bak）- ログインだけやり直す。
codex logout→codex login（手元にブラウザーがなければcodex login --device-auth）- 認証の保存先とログを確認する。
cli_auth_credentials_storeにより、保存先はファイルまたはOSの資格情報ストアで、ephemeral設定では現在のプロセスのメモリ内だけに保持されます。auth.jsonがないことは異常とは限らず、削除だけで再ログインの問題が直るとも限りません。codex-login.logのエラーと、組織が許可する認証方法を確認します。- 設定エラーは表示された箇所だけ直す。エラーに出たファイル・行・設定名を公式リファレンスと照合します。バージョン差が原因なら、導入した方法に合わせてCLIを更新します。設定全体を空にすると、承認やアクセス範囲も変わるため、診断の最初の手順にはしません。変更後に同じ確認コマンドを実行し、直らなければ控えから変更箇所を戻します。
- プロジェクト側の設定も見る。信頼済みのプロジェクトでは、ルートから作業フォルダーまでの.codex/config.tomlも対象です。優先される値とエラーのファイル名を照合します
まとめ
- stream disconnected は通信の途切れ。復旧を保証せず、再開前に実行済みの操作を確認する
- usage limit は、使用量画面で再開日時と追加利用の適用条件を確認する
- 401 と
refresh_token_invalidatedは、ログインし直す - Error loading configuration は、表示された行を直すか Codex を新しくする
- アクセス拒否や接続失敗は、対象パス・通信先・OS権限を確認してからサンドボックスを調べる
ChatGPTの自律エージェント側からCodexのタスクを作る場合の消費の数え方は、ChatGPTのdots（ドッツ）とはにまとめています。
エージェントの確認ダイアログを止めて自動実行させる設定は、Antigravityの確認を無効化して自動実行する方法でも扱っています。
参考：認証、権限とサンドボックス、Windows sandbox（2026年10月23日再照合）。
掲載ログは従来の検証記録です。
今回の認証・設定診断の補足は公式資料との照合によるもので、Windowsでエラーを再発生させた結果ではありません。
