# CodexがReconnectingを繰り返すときの安全な復旧手順

> CodexがReconnecting、Thinking、Workingのまま止まる場合に、作業を保存し、会話、アプリ、認証、通信経路、一時的な障害のどこに原因があるかを小さな確認で切り分けます。

- Source: https://www.aifreeapi.com/ja/posts/codex-stuck-reconnecting-fix
- Language: ja
- Published: 2026-08-31
- Updated: 2026-09-12
- Publisher: AI Free API (https://www.aifreeapi.com)

`Reconnecting` は、Codexが切れた接続の復旧を試みている状態です。表示だけでは、以前の会話、アプリのバージョン、認証、通信経路、サービスの一時障害のどれが原因かは分かりません。

最初から`~/.codex`や会話履歴、ログイン情報を一括で削除すると、原因を調べるための記録まで失います。リポジトリの変更がディスクに残っていても、最後の指示、承認、ツールの実行結果、どこまで完了したかは会話側で確認する必要があります。

`Reconnecting 1/5`から`5/5`まで進み、次のエラーで止まった場合は、再送信より先に作業を保全してください。

```text
stream disconnected before completion
```

最後の依頼文、対象ファイル、完了を確認できた操作を短く記録します。外部送信や削除などの不可逆操作を含む指示はすぐに再実行しないでください。処理は完了し、結果の通知だけが画面に届いていない可能性があります。

## まず会話を消さずに原因の範囲を絞る

同じプロジェクトで、次の小さな確認を行います。

1. 新しい会話を作り、現在の作業ディレクトリを確認するなど、読み取りだけの依頼を一つ送る。
2. 内蔵ターミナルで`pwd`または`git status`を実行する。
3. CLIやIDE拡張機能も利用している場合、そちらから同じ程度の小さな依頼を送る。

結果の読み方は次のとおりです。

| 観察 | 絞れた範囲 | 次の安全な行動 |
|---|---|---|
| 新しい会話は動き、以前の会話だけが再接続する | 保存済み会話や、その応答の受信処理 | 以前の会話を残し、必要な情報を短く引き継いで新しい会話から再開 |
| CLIは動き、デスクトップアプリだけ失敗する | アプリの版、実行プロセス、通信経路 | バージョンを控えてからアプリを完全終了し、再起動 |
| シェルコマンドは動くが、アプリとCLIの両方が失敗する | 少なくとも基本コマンドは実行できている | 認証、バージョン、サービス状態、通信環境を一つずつ確認 |
| `git status`も止まる | リポジトリ、ファイルシステム、シェル、ローカルのプロセスにも問題の可能性 | 先に基本コマンドが実行できる状態へ戻す |
| 複数のアプリが、利用を許可された二つのネットワークで失敗する | アカウント、サービス、複数のクライアントに共通する問題の可能性 | ローカルデータを変えず、診断用の記録をまとめる |

![作業保存から小さな動作確認、エラー別の調査、再起動、ログ記録へ進むCodexの復旧フロー](https://www.aifreeapi.com/posts/ja/codex-stuck-reconnecting-fix/img/safe-recovery-flow.webp)

OpenAIの[公式トラブルシューティング](https://learn.chatgpt.com/docs/reference/troubleshooting#stuck-states-and-recovery-patterns)も、停止しているように見える場合は、承認待ちの有無、基本的なターミナルコマンド、新しい会話での短い依頼を確認するよう案内しています。元の会話を残したまま、問題が起きる範囲を絞れる確認です。

## バージョンはアプリ・CLI・IDEごとに記録する

CLIでは次を実行します。

```bash
codex --version
codex --help
```

デスクトップアプリはAbout画面、IDE拡張機能は拡張機能の詳細で確認します。「最新版を使っている」では比較になりません。OpenAIはDesktopとCLIに異なるCodexのバージョンが入る場合があると説明しています。

更新によって改善する場合もあります。公式の[ChatGPT & Codex changelog](https://learn.chatgpt.com/docs/changelog)では、Codex CLI 0.148.0で提供元の一時障害に伴う応答の再接続が改善されました。同日のクライアント更新には、待機中や再接続後に会話が利用できなくなる問題の修正もあります。

ただし、リリースノートに修正が載っていても、すべての再接続エラーが古い版で起きるとは限りません。更新後は同じ短い依頼を試し、ほかの設定を同時に変えずに結果を比較してください。

## 具体的なエラーが出たら、その原因を調べる

再接続回数だけでなく、エラー全文を読みます。

- `access token could not be refreshed`なら、[Codexのトークン更新エラーの対処](/ja/posts/codex-access-token-could-not-be-refreshed)へ進む。
- HTTP 429や利用上限、リセット時刻が表示されるなら、[Codexの利用制限](/ja/posts/codex-rate-limits)へ進む。
- コマンド、MCPサーバー、クラウド設定の取得などのタイムアウトが明示されるなら、[Codexのタイムアウトの切り分け](/ja/posts/codex-timeout)で待機対象を確認する。
- `stream disconnected before completion`と再接続だけなら、利用上限や認証の問題と決めつけず、応答を受信する接続を調べる。

応答が途切れたという理由だけでログアウトすると、認証状態も変わり、元の原因が通信か認証かを比較しにくくなります。認証エラーが明示されている場合は、エラー原文を保存してから再認証してください。

## Codexを実行している環境で通信を比較する

ブラウザーでChatGPTを開けても、Codexアプリ、ターミナル、VS Code拡張機能、WSL、コンテナー、Remote SSHが同じ通信設定を使うとは限りません。プロキシ、DNS、信頼する証明書、ファイアウォールの設定を、実際にCodexが動いている環境で確認します。

まずプロセスが動く端末やリモート環境を特定します。アカウント、プロジェクト、バージョン、依頼の大きさをそろえ、利用を許可されている通信条件を一つだけ変えて比較します。

- 社内ネットワークと、業務利用を許可された別のネットワークを比較する。
- 組織の方針で許可されている場合だけ、VPN接続の有無を比較する。
- ローカルのプロキシが必要なら、待ち受けポートと、Codex側に渡された設定を確認する。
- WSL、コンテナー、Remote SSHで失敗するなら、その環境から確認する。

変更前後の時刻、最後の状態、エラー原文を記録します。別のネットワークで回復すれば元の通信経路が関係する可能性は高まりますが、DNS、TLS検査、WebSocket、プロキシ設定のどれが原因かまでは一度の比較では決められません。

### コマンド用のプロキシとCodexの応答接続は別に確認する

`.env`、`HTTP_PROXY`、WebSocket設定を一括で直す案をそのまま使うと、次の二つの通信を混同するおそれがあります。

1. Codexがモデルからの応答を受け取る接続
2. Codexがサンドボックス内で実行するコマンドの外部通信

OpenAIの[権限設定の仕様](https://learn.chatgpt.com/docs/permissions#scope-and-enforcement)でプロキシが制御するのは、**サンドボックス内のコマンドによる通信**です。`curl`やパッケージマネージャーの通信経路が変わっても、Codexアプリがモデルの応答を受信する経路まで変わった証明にはなりません。モデルや認証への通信は、クライアント側のHTTP・システムプロキシ設定を使います。

現在の公式設定リファレンスにないキーを、恒久的な解決策として追加しないでください。設定を比べるなら変更前の値を保存し、一項目ずつ変更して元へ戻せるようにします。独自のモデル提供元を設定している場合は、そのサービスと使用中のCodexが対応する通信方式も確認してください。

![新しい会話、基本コマンド、別アプリ、別ネットワークの結果から、再接続エラーの原因を絞り込む図](https://www.aifreeapi.com/posts/ja/codex-stuck-reconnecting-fix/img/reconnecting-cause-isolation-map.webp)

## 症状に合わせて再起動する範囲を決める

以前の会話だけが失敗する場合は、その会話を残します。新しい会話へ目的、完了した作業、対象ファイル、不明点を引き継ぎ、最初に`git status`を確認してもらいます。

一つのアプリだけが失敗する場合は、ほかの実行中の作業が終わってから、そのアプリやIDEのプロセスを完全終了して開き直します。ウィンドウを閉じただけではプロセスが残る場合があります。公式のトラブルシューティングも、実行中の会話が完了してから再起動するよう案内しています。

すべての環境で失敗する場合は、[OpenAIの稼働状況](https://status.openai.com/)を確認し、発生時刻を記録してから通信条件を一つだけ変えて比較します。原因が絞れていない段階で再インストールやキャッシュ削除を繰り返しても、診断材料は増えません。

再接続後は`git status`を確認し、外部サービスを操作していた場合は、その実際の状態も確かめます。最終メッセージが届かなくても、ツールの実行や書き込みが完了している可能性があるためです。

## 会話データを扱う前に記録を残す

OpenAIは次の保存場所を案内しています。

- macOSアプリのログ： `~/Library/Logs/com.openai.codex/YYYY/MM/DD`
- 通常の会話記録： `$CODEX_HOME/sessions`（通常`~/.codex/sessions`）
- アーカイブ済みの会話記録： `$CODEX_HOME/archived_sessions`

依頼文、パス、リポジトリ名、ツール出力などに機密情報が含まれる場合があります。共有前に確認し、トークン、Cookie、メールアドレス、非公開コードを取り除いてください。データディレクトリ全体を送る必要はありません。

同じプロジェクトの新しい会話が安定して動き、特定の古い会話だけが失敗する場合は、その会話の記録をサポートに示します。会話ファイルを移動する必要があると案内された場合も、復元できるコピーを先に作り、対象だけを扱ってください。日付だけを基準に大量削除する方法は避けます。

問題が残る場合は、`/feedback`用にアプリの種類とバージョン、OSと実行環境、発生時刻とタイムゾーン、`Reconnecting`表示の推移、各比較の結果をまとめます。ログは機密情報を除いた必要最小限の範囲を添えます。

復旧の確認では、再接続の表示が一度消えたことだけで判断せず、失敗していた環境で同じ小さな依頼が完了するか確かめてください。特定の会話、アプリ、通信経路のどこまで動作を確認できたかを残せば、元の作業をどこから再開するか判断できます。