AIFreeAPI Logo

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

A
9 min readOpenAI Codex

Reconnecting 1/5〜5/5だけでは原因は決まりません。最後の指示と変更ファイルを保全し、新規task、基本command、別surface、network条件一つの順で範囲を絞ります。

Codex Reconnecting 5/5で作業を保全し、4つの小さな確認、結果の切り分け、surface別version、error route、restart、logとfeedbackへ進む安全な復旧手順

Reconnecting は、Codexが切れた接続の復旧を試みている状態です。表示だけでは、古いtask、client version、authentication、network route、一時的なservice interruptionのどこに原因があるかは分かりません。

最初から~/.codex、全session、login情報を削除すると、比較に必要な証拠まで失います。repositoryの変更はdiskに残っていても、未完了taskには最後の指示、approval、tool output、確実に終わったstepが残っています。

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

text
stream disconnected before completion

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

まずtaskを消さずに範囲を絞る

同じprojectで、次の小さな確認を行います。

  1. 新しいtaskを作り、current directoryの確認などread-onlyの依頼を一つ送る。
  2. integrated terminalでpwdまたはgit statusを実行する。
  3. CLIやIDE extensionがある場合、同じ程度の小さな依頼を別surfaceから送る。

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

観察絞れた範囲次の安全な行動
新規taskは動き、古いtaskだけが再接続する保存済みtaskまたはそのresponse stream古いtaskを残し、短いhandoffで新規taskから再開
CLIは動き、Desktopだけ失敗するDesktop build、host process、またはそのrouteversion比較後にDesktopを完全終了して再起動
shell commandは動くが複数のCodex surfaceが失敗するproject command自体は主原因ではないauth、version、service、networkを一条件ずつ確認
git statusも止まるrepository、filesystem、shell、local processの問題が別にある先に基本commandを復旧
複数surfaceが二つの許可済みnetworkで失敗するaccount、service、広いclient failureの可能性local dataを変えずdiagnosticを作成
Codex Reconnectingの安全な復旧フロー。4つの小さな確認、結果の読み方、明確errorと再接続だけの場合の分岐、最小restart、記録、公式logとfeedback準備を示す
Codex Reconnectingの安全な復旧フロー。4つの小さな確認、結果の読み方、明確errorと再接続だけの場合の分岐、最小restart、記録、公式logとfeedback準備を示す

OpenAIの公式Troubleshootingも、stuck stateではapproval待ち、基本的なterminal command、新しい小さなchatを最初に確認するよう案内しています。これらは元taskを壊さず、責任境界を分けられるテストです。

versionはsurfaceごとに記録する

CLIでは次を実行します。

bash
codex --version codex --help

DesktopはAbout、IDE extensionはextension詳細で確認します。「最新版を使っている」では比較になりません。OpenAIはDesktopとCLIに異なるCodex versionが入る場合があると説明しています。

updateを早めに確認する根拠もあります。公式のChatGPT & Codex changelogでは、Codex CLI 0.148.0でtemporary provider outage中のturn reconnectが改善されました。同日のclient更新には、idleまたはreconnecting後にtaskが利用できなくなる問題の修正もあります。

ただし、release noteは「すべての再接続はold versionが原因」という意味ではありません。更新後は同じminimal requestだけを再試行し、別の設定を同時に変えないでください。

error textが明確なら別の問題として扱う

再接続回数だけでなく、最後までerrorを読みます。

  • access token could not be refreshedなら、Codex token更新の復旧へ進む。
  • HTTP 429、usage limit、reset timeなら、Codex rate limitへ進む。
  • command、MCP server、cloud config bundleのtimeoutが明示されるなら、Codex timeoutの切り分けで待機対象を確認する。
  • stream disconnected before completionと再接続だけなら、limitやauthと決めずclient streamの範囲を調べる。

一般的なstream interruptionだけを理由にlogoutしないでください。logoutはauthentication stateを変えるため、元の原因がnetworkかtokenか比較しにくくなります。明確なauth errorがある場合に、original errorを保存してから再認証します。

Codexが動いているhostでnetworkを比較する

browserでChatGPTを開けても、Codex Desktop、terminal、VS Code extension host、WSL、container、Remote SSHが同じproxy、DNS、certificate trust、firewall routeを使うとは限りません。

まずprocessが動くhostを確認します。account、project、client version、request sizeを固定し、許可された条件を一つだけ変えます。

  • managed office networkと許可済みの通常networkを比較する。
  • policyで許される場合だけVPN on/offを一度比較する。
  • local proxyが必要ならprocessのlisten portと、Codex hostが受け取る環境を確認する。
  • WSL、container、Remote SSHで失敗するなら、その環境から確認する。

変更前後の時刻、最後のstatus、exact errorを記録します。別networkで回復すれば元routeの関与は強まりますが、DNS、TLS inspection、WebSocket、proxy ruleのどれかまでは一回で断定できません。

command用proxyとCodexの応答接続は同じではない

.envHTTP_PROXY、WebSocket設定を一括で直す案をそのまま使うと、二つのnetwork planeを混同します。

  1. Codex clientがmodel responseを受け取る接続
  2. Codexがsandbox内で実行するcommandのoutbound network

OpenAIのpermissions configuration specでnetwork proxyが制御するのは sandboxed command traffic です。HTTP(S)やWebSocketのproxy variablesをtoolへ渡せますが、curlやpackage managerのrouteが変わったことは、Desktop Appのmodel streamが変わった証明にはなりません。

現行の公式config referenceにないkeyを、恒久的な解決策として追加しないでください。必要な比較ならbefore valueを保存し、一項目だけ変更し、rollbackできる状態にします。custom model providerの場合は、そのproviderとinstalled Codex versionのtransport仕様を確認します。

Codex Reconnectingの原因切り分けマップ。作業保全、新規task、基本command、別surface、別networkの確認結果からclient、task state、認証、network、local environment、一時service障害へ分岐する
Codex Reconnectingの原因切り分けマップ。作業保全、新規task、基本command、別surface、別networkの確認結果からclient、task state、認証、network、local environment、一時service障害へ分岐する

restartの範囲を症状に合わせる

古いtaskだけが失敗する場合は、元taskを残します。新規taskへgoal、完了step、file list、不明点だけを渡し、最初にgit statusを確認させます。

一つのclientだけが失敗する場合は、他のactive tasksが終わるまで待ち、AppまたはIDE hostを完全終了して開き直します。windowを閉じてもbackground processが残る場合があります。公式Troubleshootingも、active chats完了後のrestartを案内しています。

全surfaceが失敗する場合は、OpenAI Statusを確認し、local timeを保存してからnetwork一条件だけを比較します。原因範囲が広いままreinstallやcache削除を繰り返しても、診断材料は増えません。

再接続後はgit statusと外部systemの実状態を確認します。final messageが届かなくても、toolやwriteが完了している可能性があるためです。

session削除は最後の検証にする

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

  • macOS App log: ~/Library/Logs/com.openai.codex/YYYY/MM/DD
  • active transcript: $CODEX_HOME/sessions(通常~/.codex/sessions
  • archived transcript: $CODEX_HOME/archived_sessions

prompt、path、repository名、tool outputなどの機密情報が含まれる場合があります。共有前に確認し、token、cookie、email、private codeを除いてください。data directory全体を送る必要はありません。

同projectの新規taskが安定して動き、特定の古いtaskだけが失敗する場合に限り、そのtranscriptの隔離を検討できます。まずrecoverable copyを作り、対象fileだけをactive directoryの外へ移し、同じminimal testを実行します。日付だけで大量削除しないでください。

問題が残る場合、/feedback用にsurfaceとversion、OSと実行host、発生時刻とtimezone、Reconnectingのsequence、新規task・別surface・基本command・network比較の結果、最小限のredacted logをまとめます。

復旧を確認できた状態とは、badgeが一度消えたことではありません。「一つのsaved task」「一つのclient」「一つのnetwork route」「すべてのsurface」のどこに問題があるか説明でき、同じ小さなテストで再確認できることです。