Codex CLI「Reconnecting」復旧ガイド｜WebSocketフォールバックとv0.136.0対応（2026年6月）¶

Q: 再接続バナー後の二重実行を避けるには？

/status で approval_policy と sandbox_mode が変わっていないか確認し、同じプロファイルで再起動する。--transcript ... --append を付け、TodoWrite の直近 1 から 3 項目だけを再投入すると境界を明確にできる。

Q: ネットワーク許可が必要なまま再起動する手順は？

--sandbox workspace-write と -c 'sandbox_workspace_write.network_access=true' を再付与してから再実行する。許可が外れると再試行がサイレント失敗し、ループしやすくなる。

Q: 復旧手順を監査用に残すには？

analysis/ _reconnect.jsonl に transcript を保存し、/status と最初の curl または gh api 成功結果を同じログに残して TodoWrite に貼り付ける。

Q: Rust版（v0.106.0+）で「Re-connecting」ループは解消されましたか？

大幅に改善されたが、完全には解消されていない。最新 stable の v0.136.0 でも、WebSocket fallback遅延、アイドル後の再接続失敗、subagent起因のstream disconnectなどのopen issueが残る。

Q: 同時に何本までCodexセッションを開けるか？

コミュニティ報告では 3 本以上の並列で一斉ハングが起きやすいとされている。重要タスクは 1 セッションずつ処理し、補助タスクは別端末へ分散する運用が無難である。

Q: /feedbackコマンドで何が送信されるか？

リクエスト ID、環境情報、接続状態のスナップショットなどが送信される。提出前に ~/.codex/log/codex-tui.log を確認し、不要な個人情報が含まれていないか確認すると安全である。

Codex CLI 完全ガイド

対象 / ポイント

Codex CLIで「Reconnecting」または「Re-connecting」ループに遭遇したユーザー向け。 WebSocket fallback、プロキシ、MCP、VS Code、Windows/WSL、長時間セッション、subagent要因を切り分ける。

2026年5月以降の検索意図は、旧来の複数セッション一斉ハングだけでなく、WebSocket起動失敗からHTTP/SSEへフォールバックする遅延に寄っている
Reconnecting... 1/5 から 5/5 のあと応答が返る場合、壊れたインストールではなくWebSocketフォールバック遅延として切り分ける
2026-06-03時点の最新stableは v0.136.0（2026-06-01公開）。同日のGitHub Releasesには v0.137.0-alpha.4 もpre-releaseとして出ている
まず更新確認、症状分類、単体セッション化を行い、その後に認証、WebSocket/プロキシ、MCP、IDE拡張、subagent要因を切り分ける
APIキー認証は公式に用意された代替手段だが、すべての再接続ループを直す万能策ではない

2026年6月3日時点の現況

Codex の最新 stable リリースは v0.136.0 で、GitHub Releases では 2026-06-01 公開と確認できる。同じページには v0.137.0-alpha.4 が 2026-06-03 のpre-releaseとして掲載されている。v0.136.0では、5分前のChatGPT認証更新、remote-control WebSocketのserver token化、Windows sandboxクリーンアップなどが入ったが、再接続問題は改善中であって完全解決とは言い切れない。⁶

現在のopen issueでは、WebSocketフォールバック（#19821、#23665、#24045）、subagent起因のstream failure（#24475）、アイドル後・セッション永続化まわりの問題（#15841、#15870）が残っている。⁷⁸¹⁹¹⁰⁵

そのため本記事は、現在の事実 と v0.50.0時代の歴史的経緯 を分けて扱う。古い節は背景情報として読み、最新状況の判断は冒頭の現況と後半のまとめを基準にする。

まず症状を分ける¶

見えている症状	可能性が高い分類	最初の対応
`Reconnecting... 1/5` から `5/5` のあと、最終的に応答が返る	WebSocket起動タイムアウト後のHTTP/SSEフォールバック。プロキシや制約の強いネットワークで目立つ	latest stableへ更新し、毎回発生する場合だけHTTP/SSEプロファイルを試す
`Reconnecting...` のあと `401`、`403`、ログイン関連エラーが出る	認証・アカウント状態	`codex logout` と認証キャッシュ整理で、使う認証方式を1つに揃える
1〜2時間アイドル後、AppやIDE拡張で再接続できない	App/拡張のアイドル接続状態	Appまたは拡張を再起動し、近いopen issueへ診断情報を添える
subagent / background agent開始時だけ再接続が始まる	multi-agentまたはapp-server stream負荷	単体agentで再実行するか、タスクを小分けにする
複数ターミナルが同時に止まる	旧来の複数セッション・session recovery問題	全Codexプロセスを止め、60秒待って1セッションだけ再起動する

以下は2025年10月時点（v0.50.0）の記録である。

Codex CLI（v0.50.0時点）で「Re-connecting...」ループに陥る報告が継続していた（Issue #5575、#5679、#5505など）。本記事では、この既知不具合の当時の状況と環境別の実用的ワークアラウンドを一次情報ベースでまとめる。

当時の状況：0.50.0では未解決

バージョン0.50.0（2025年10月末時点で利用可能）では"Re-connecting"問題は根本解決していなかった。原因は複合的で、上流接続の不安定性、セッション復帰処理、VS Code拡張との干渉、認証設定、WSL2/ネットワーク環境などが絡んでいた。

これはあなたの環境だけの問題ではない。多数のユーザーが同様の症状を報告しており（GitHub Issue #5575）、OpenAIチームが修正に取り組んでいた。

現在の低リスク切り分け順

まず更新確認: codex --version で latest stable にいるか確認
変数を減らす: 可能なら単体セッション・MCPなし・拡張なしで再現を取る
認証キャッシュを確認: Codex は ~/.codex/auth.json または OS の credential store にログイン状態を保存する⁴
その後に切り分け: 認証方式、MCP、IDE 拡張、Windows / WSL 境界の順で潰す

問題の症状¶

GitHub Issue #5679 で報告された症状は以下の通りだ：

典型的な発生パターン¶

Codex CLIでタスクを開始
通常1〜3ステップ実行後、突然「Re-connecting...」が繰り返し表示される
再接続に成功しても、数ステップ後に再びループが発生
再ログイン・プラグイン再インストール・別ネットワークでも解決しない

影響を受けるユーザー¶

Codex CLI 0.47.x以前のバージョン使用者
特にWSL2/Windows環境のユーザー
長時間実行タスクを行うユーザー

何が起きているのか（0.50.0時点の状況）¶

複合的な原因¶

Issue #5575および関連Issueから、以下の複合要因が確認されている：

上流接続の不安定性
WebSocket/SSEストリームの切断後、復帰処理が失敗し"Re-connecting"で停滞
複数セッション同時運用時に一斉ハングが発生（一日に一度の頻度で報告あり）
VS Code拡張との干渉
Issue #5505：拡張側で"Re-connecting"を繰り返すケース
拡張のバージョン・設定との相性問題
認証設定の競合
Issue #3835：OAuthとAPIキーの併用状態で挙動が不安定化
環境変数にAPIキーが残っていると接続エラーが発生
WSL2/ネットワーク環境
WSL2環境特有のネットワークスタック問題
VPN/プロキシ/セキュリティ製品による干渉

バージョン履歴と現状¶

0.48.0（2025年10月末）：イベント出力拡充、自動コンパクト、WSL関連更新
0.50.0（2025年10月末）：段階的改善が継続中
0.117.0（2026-03-26）：Rust版で認証リフレッシュまわりの改善が進む
0.125.0（2026-04-24）：2026-04-27 時点の latest stable（release）
0.136.0（2026-06-01）：2026-06-03 時点の latest stable⁶
現状：改善は進んでいるが、WebSocketフォールバック、プロキシ、アイドルセッション、subagent stream関連のopen issueが残る⁷⁸¹⁹¹⁰⁵

バージョン日付について

正式なリリース日や修正内容は、Codex GitHub Releases を基準に確認する。⁶

公式の対応状況

2025年10月のclosed issueは背景情報として有用だが、現在の判断材料はGitHub Releasesと、2026年5月以降に残るopen issueである。

実用的ワークアラウンド（優先順位順）¶

以下のワークアラウンドを1から6の順に試す。5回のWebSocket retry後に復帰するだけなら、最初から認証情報や設定を壊さない。

ワークアラウンド比較表（全体像の把握に便利）¶

方法	効果が高いシナリオ	所要目安	成功シグナル
方法1	古いビルドで再接続問題が出ている	約2分	v0.136.0以降のstableへ更新済み
方法2	複数セッションが一斉ハングして前進できない	約2分	新規1セッションが `HELLO` に応答する
方法3	毎回 `Reconnecting... 1/5` から `5/5` のあとHTTP/SSEで復帰する	約5分	WebSocket retry待ちなしで開始できる
方法4	`401`、`403`、ログインループ、認証方式の切替がある	約5分	`codex login status` が意図した認証方式と一致する
方法5	MCP、IDE拡張、subagentを使うと再現する	約10分	CLI単体 / MCPなし / 単体agentでは動く
方法6	WindowsまたはWSL固有の断続的切断	約3分	native WindowsまたはWSL側に再現範囲を絞れる

方法1: 更新して症状を分類する¶

codex --version

# macOS/Linuxのstandalone installer
curl -fsSL https://chatgpt.com/codex/install.sh | sh

# npmで入れている場合
npm install -g @openai/codex@latest

更新後、短いプロンプトを投げる。Reconnecting... 1/5 から 5/5 のあと応答が返るだけなら、ローカルインストール破損ではなくWebSocketフォールバック遅延として扱う。

2026年の重要な見方

新しいopen issueでは、WebSocketセットアップがタイムアウトし、Codexがretryしたあと responses_http / SSE に落ちてturnが完了するパターンが報告されている。¹¹⁰

方法2: 全インスタンス停止→単体再起動¶

Issue #5575で最も多くの成功報告があるワークアラウンド：

# 1) 全Codexプロセスを完全終了（Ctrl+C）
# 2) 60秒待機（バックグラウンドプロセスの完全終了を確認）
# 3) 1つだけ再起動
codex

# 4) 短文で応答確認
# プロンプトで "HELLO" などを入力し、即応性をチェック

成功報告多数

複数セッション同時運用が一斉ハングの主要因である。この手順で復帰したという報告が最も多く、日常運用フローとして定型化することを強く推奨する。

方法3: WebSocketフォールバックが毎回起きる場合のHTTP/SSEプロファイル（上級）¶

Reconnecting... 1/5 から 5/5 まで毎回待たされたあと、HTTP/SSEフォールバックで成功する場合、とくにプロキシ環境ではWebSocketを使わない別プロファイルが報告ベースの回避策になる。公式config referenceには model_providers.<id>.supports_websockets があり、最近のissueでもプロキシ環境向けの実用策として言及されている。¹²³

以下をユーザーレベルの ~/.codex/config.toml に追加する。project local configには置かない。

[profiles.http_sse]
model_provider = "openai-http"

[model_providers.openai-http]
name = "OpenAI HTTP/SSE"
base_url = "https://api.openai.com/v1"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

新しいセッションで試す。

codex --profile http_sse

可逆な回避策として使う

built-inの openai provider ID は上書きしない。OpenAIのconfig docsではbuilt-in IDが予約されている。このprofileで 401、応答低下、利用可能モデルの変化が起きる場合は、profileを削除してdefault providerへ戻す。²

方法4: 認証キャッシュのリフレッシュ¶

Codex の公式 auth docs では、ログイン情報が ~/.codex/auth.json または OS の credential store に保存されると案内されている。認証まわりが怪しい場合は、このキャッシュ状態をいったん整理するのが妥当である。⁴

# 1) ログアウト
codex logout

# 2) 認証ファイルを削除（残骸をクリア）
rm -f ~/.codex/auth.json

# 3) 環境変数のAPIキーを一時的に無効化（競合回避）
unset OPENAI_API_KEY

# 4) 意図した認証方式で再ログイン
codex login
# または: printenv OPENAI_API_KEY | codex login --with-api-key

認証競合について

Codex は ChatGPT ログインと API キーログインの両方を公式にサポートしている。重要なのは、キャッシュを整理したあとに どちらの認証方式で使うかを曖昧にしないこと だ。OpenAI の auth docs では、プログラム的な CLI ワークフローには API キー認証を使う 方針も案内されている。⁴¹¹

cli_auth_credentials_store = "keyring" や auto を使っている場合、資格情報の一部は ~/.codex/auth.json ではなく OS の credential store に保存される。その場合は rm ~/.codex/auth.json だけでは消え切らないため、まず codex logout を実行するのが公式に沿った手順である。⁴¹¹

方法5: MCP・IDE拡張・subagentの切り分け¶

Issue #5619、Issue #5208で報告されているMCP関連の相性問題：

実験的MCPクライアントの切替¶

~/.codex/config.tomlを編集：

# ON/OFFを切り替えて挙動を確認
experimental_use_rmcp_client = false  # または true

問題のあるMCPサーバーを一時無効化¶

# 問題が疑われるMCPサーバーをコメントアウト
# [mcp_servers.problematic_server]
# command = "..."

MCP関連の既知問題

SSE/HTTP2周辺の仕様不整合が直近で多数報告されている。特にストリーミング接続でハンドシェイクが失敗するケースがある。

VS Code拡張の干渉回避¶

Issue #5041で報告されている拡張側のネットワークブロック問題：

VS Code拡張を一時的に無効化
CLI単体でcodexを実行
問題が解消されれば、拡張の設定・バージョンを確認

既知の拡張バグ

VS Code拡張がネットワークアクセスを阻害する既知事象がある。CLI単体での動作確認を優先する。

subagent / background agent負荷を下げる¶

最近の報告では、通常の単体agentタスクは動くが、subagentやbackground agentを起動したときだけ Reconnecting... 1/5 から 5/5、さらに stream disconnected before completion に進むケースがある。⁵

同じ依頼を単体agentで再実行する
repo全体の大きな依頼を小さなpromptに分ける
5/5 後に失敗する場合、Codexが表示するrequest IDを控える

方法6: Windows / WSL環境をリセットまたは切り分ける¶

Issue #5084および公式Windowsガイドの推奨手順：

# PowerShellで実行
wsl --shutdown

# 1分待機後、WSL2を再起動

Windows環境について

OpenAIの現行Windows docsでは、native Windows sandboxをdefaultとして使い、Linux-native環境が必要な場合や開発ワークフローがWSL2内にある場合にWSL2を選ぶ形になっている。再現確認時は、同じrepoを C:\ とWSLパスの両方で混ぜて扱わない。¹²

バージョン管理と再配備¶

破損時の完全再インストール¶

# npm経由での完全再配備（破損リセット）
npm uninstall -g @openai/codex
npm install -g @openai/codex@latest

# 認証情報もクリアする場合
rm -rf ~/.codex

診断情報の提出（0.50.0で強化）¶

0.50.0リリースで/feedbackコマンドが強化され、開発チームへの診断情報提出が容易になった。

# Codexセッション内で実行
/feedback

提出される情報：

リクエストID
エラーログ
システム環境情報
接続状態のスナップショット

Issue報告時の推奨情報

再現ログを共有する際は、以下の情報を含めると修正が進みやすい：

発生日時・頻度
同時実行セッション数
接続経路（VPN/Proxy有無）
IDE/拡張の使用状況
codex --versionの出力
/feedbackで取得したリクエストID
ログファイル（~/.codex/log/codex-tui.log）

まとめ¶

Codex CLI の「Reconnecting」/「Re-connecting」問題は、2026-06-03 時点でも継続中として扱うのが安全だ。stableは v0.136.0 まで進んだが、公式の根拠は今も次の3系統に分かれている。⁶⁷⁸¹⁹¹⁰⁵

出荷済み修正: Codex GitHub Releases
WebSocket / fallback未解決事例: #19821、#23665、#24045
アイドル・セッション・subagent事例: #15841、#15870、#24475

したがって、問題は 改善されたが終了していない と捉えるのが妥当である。この記事は「codex reconnecting」の検索意図に対する解になっているが、読者が自分の症状をWebSocket fallback遅延、認証問題、複数セッションハング、統合要因のどれかに即分類できる構成であることが条件になる。

即応チェックリスト（推奨実行順）¶

latest stableへ更新して症状を分類する（codex --version と短いテストprompt）
毎回 Reconnecting... 1/5 から 5/5 のあと復帰するなら、別セッションで HTTP/SSEプロファイル を試す¹²³
複数セッションが一斉に止まるなら、全停止 -> 60秒 -> 単体再起動 を行う（HELLOで疎通確認）
認証エラーが出るなら、認証リフレッシュ：codex logout -> rm ~/.codex/auth.json -> unset OPENAI_API_KEY -> codex login⁴¹¹
統合機能で再現するなら、CLI単体 / MCPなし / 単体agent で切り分ける

このチェックリストで多くのケースが復旧します

重要なのは、見た目が似た「Reconnecting」を同じ原因として扱わないことだ。WebSocket fallback遅延、認証ループ、subagent stream failureはUI上は似ているが、必要な対処が異なる。

最近の接続安定性改善（v0.115.0〜v0.136.0）¶

バージョン	改善内容	PR
v0.136.0（2026-06-01）	5分前のChatGPT auth refresh、remote-control WebSocketのserver token化、sandbox cleanup	GitHub Releases
v0.135.0（2026-05-28）	`codex doctor` の環境/thread診断拡充、`/status` のremote connection表示	GitHub Releases
v0.134.0（2026-05-26）	staleなexec-server WebSocket clientの再接続などremote reliability改善	GitHub Releases
v0.125.0（2026-04-24）	app-serverのWebSocketクライアントがturn/tool-output通知の集中時に切断されにくくなり、Windows sandbox起動まわりも改善	#19246, #19044
v0.117.0（2026-03-26）	認証トークン永続失敗後のリフレッシュストーム停止	#15530
v0.117.0	アクセストークン有効期限を使った事前認証リフレッシュ	#15545
v0.116.0（2026-03-19）	WebSocket prewarmタイムアウト＋クリーンフォールバック	#14838
v0.115.0（2026-03-16）	ローカルプロキシがCONNECTをHTTP/1.1で提供（プロキシ互換性向上）	—

最新の進捗はGitHub Releasesで確認する。⁶

追加の運用メモ（2025年12月）¶

再接続バナー後の二重実行を避けるには？

/status で approval_policy / sandbox_mode が変わっていないか確認し、同じプロファイルで再起動。--transcript ... --append を付け、TodoWriteの直近1〜3項目だけをリプレイして境界を明確にする。

ネットワーク許可が必要なまま再起動する手順は？

--sandbox workspace-write -c 'sandbox_workspace_write.network_access=true' を再付与してから再実行。許可が外れると再度ループしやすくなる。ドメインレベルのフィルタリングが必要な場合は、ChatGPTのWeb環境のInternet Access設定を使用する。

復旧手順を監査用に残すには？

analysis/<date>_reconnect.jsonl にトランスクリプトを保存し、/status と最初の curl/gh api 成功結果を同じログに残してTodoWriteへ貼り付ける。

FAQ（よくある質問）¶

Rust版（v0.106.0+）で「Re-connecting」ループは解消されましたか？

大幅に改善されたが、完全には解消されていない。最新stableの v0.136.0 でも、WebSocket fallback遅延、アイドル後の再接続失敗、subagent起因のstream disconnectなどのopen issueが残っている。⁶⁷¹⁹¹⁰⁵

5回Reconnectingしてから普通に応答するのは何か？

WebSocket経路が失敗またはタイムアウトし、その後CodexがHTTP/SSEへfallbackしてturnを完了している可能性が高い。毎回発生する場合は、更新後にHTTP/SSE専用profileを可逆な回避策として試す。¹¹⁰³

WebSocketを無効化すべきか？

WebSocket retryが毎回の遅延原因で、HTTP/SSEでは動く場合だけ試す。default設定を壊さず、別profileに分けて、認証・モデル・性能に副作用があればすぐ戻す。¹²³

同時に何本までCodexセッションを開けるか？

コミュニティ報告では、3本以上並列で動かすと1日に1回は一斉ハングが発生するケースが多いとされている。重要タスクは1セッションずつ処理し、他はバックアップ端末に分散する運用が推奨である。

/feedbackコマンドで何が送信されるか？

リクエストIDや環境情報、接続状態のスナップショットなどを自動収集する。公開範囲を懸念する場合は、提出前に~/.codex/log/codex-tui.logを確認して余計な個人情報が含まれていないかチェックする。

Issue報告時の推奨情報¶

再現ログを共有可能な場合、以下の情報を含めてIssue #5575または新規Issueに報告すると、修正の優先度が上がる：

発生日時・頻度
同時実行セッション数
接続経路（VPN/Proxy有無）
IDE/拡張の使用状況
codex --versionの出力
/feedbackで取得したリクエストID
ログファイル（~/.codex/log/codex-tui.log）

監視すべきIssue¶

Issue #13041：WebSocket 1008 Policy close（Open）
Issue #19821：WebSocket connect failure before HTTP fallback（Open）
Issue #23665：fallback後のWebSocket自動復帰（Open）
Issue #24045：新規/再開threadでの回復可能reconnect loop（Open）
Issue #24475：subagent起因のstream disconnect（Open）
Issue #15841：アイドル後の再接続失敗（Open）
Issue #15870：初期トランスポート障害後のセッション復帰不可（Open）
Issue #15014：WebSocketフォールバック + タイムアウト（Open）

Issue	概要
#5575	全インスタンス一斉ハング
#5679	Re-connectingループの繰り返し
#5619	MCP/SSEストリーミング接続失敗
#5505	VS Code拡張での再接続ループ
#5041	VS Code拡張のネットワークブロック
#3216	`codex exec`内での無限ループ