Codexが止まった原因をログで調べる｜終了コード・権限待ちの技術診断

Codexの画面操作や通信状態は確認したものの、止まった原因をログの証拠から特定したい人向けの記事です。すぐに同じ指示を送り直すと、最初の処理が裏で続いていた場合に二重実行となり、ファイル変更や外部操作が重なるおそれがあります。

先に見るのは、画面の動きではなく「最後に何が出力されたか」です。止まり方を待機、コマンド失敗、権限待ちの3種類へ分けると、次に確認すべき場所が決まります。ログを読む前に許可ボタン、指示の迷い、通信・端末の問題を確かめたい場合は、Codexが途中で止まるときの初心者向け診断から始めてください。

「止まった」を3種類に分ける

最初に、直前の状態を次の3つへ仮分類します。

状態	最後に見えるもの	確認する証拠	最初の対応
待機	質問、選択肢、追加情報の依頼	未回答の項目があるか	質問へ答える
コマンド失敗	エラー文、失敗したコマンド、非ゼロの終了コード	終了コード、標準エラー、生成物	原因を1つ直してから再実行する
権限待ち	承認、ログイン、アクセス許可の要求	操作対象、書き込み先、ネットワーク利用	影響範囲を確認して判断する

これは画面表示を見ただけの確定診断ではありません。Codexの製品、利用環境、設定によって表示は変わるため、実際のボタン名や文言は※要確認です。ただし、待機中の処理へエラー修正を始めたり、失敗中の処理をただ待ち続けたりする取り違えは、この分類で減らせます。

最後の出力を読む

ログは最終行だけでなく、その少し前から読みます。見る順番は「実行した操作」「標準出力」「標準エラー」「Codex自身の説明」です。標準出力は通常の結果、標準エラーは診断メッセージが書かれる出力先です。ただし、標準エラーに文字が出たことだけで失敗とは限りません。最終的な成功・失敗は終了コードや生成物でも確認します。

たとえば、次のような匿名化したメモを作ります。

操作: 記事ファイルの検査
最後の正常出力: 14 files checked
最初の異常出力: command not found
終了コード: 127
変更されたファイル: なし

エラー文は途中を省かず保存しつつ、公開用のメモからはユーザー名、メールアドレス、トークン、ローカルの絶対パスを除きます。プロジェクトの置き場所そのものが原因に見える場合は、Claude Codeでフォルダを使い分ける基本で作業ディレクトリの考え方も確認できます。

終了コードを確認する

終了コードは、コマンドが終わった結果を数値で返す仕組みです。一般に0は成功、0以外は何らかの失敗を表します。ただし、数字の詳しい意味は実行したコマンドごとに異なるため、エラー本文とセットで読みます。

PowerShellでネイティブコマンドを実行した直後は、次のように確認します。

npm test
$LASTEXITCODE

Microsoft Learnによると、$LASTEXITCODEには最後に実行したネイティブプログラムまたはPowerShellスクリプトの終了コードが入ります。ネイティブコマンドの場合、$?は終了コードが0ならTrue、0以外ならFalseになります。具体的な数値を記録したいときは$LASTEXITCODEを使います。Windowsでの確認方法を横断して比べたい場合は、終了コードの確認方法も参照してください。

POSIX系のシェルでは、直前のコマンドの状態を次のように確認できます。

npm test
printf '%s\n' "$?"

確認コマンドを先に何個も実行すると、「直前」が別のコマンドへ変わります。失敗した直後に値を控えるのが要点です。POSIX仕様では、コマンドが見つからない場合は127、見つかったが実行できない場合は126と定められています。一方、個別ツールの1や2などを共通の意味だと決めつけてはいけません。

権限待ちを見分ける

Codexの公式資料では、安全制御を「サンドボックス」と「承認ポリシー」の二層で説明しています。サンドボックスは技術的に操作できる範囲、承認ポリシーはCodexが実行前に確認を求める条件です。そのため、書き込み範囲の外やネットワーク利用で止まった場合は、コマンド自体の失敗ではなく、安全境界で待機している可能性があります。

承認画面が出たら、次の3点を読みます。

1. 何を実行しようとしているか
2. どのファイルや外部サービスへ影響するか
3. 元へ戻せるか

内容が分からないまま許可する必要はありません。「変更せず、原因調査だけ続ける」「対象をこの1ファイルへ絞る」と指示を狭める方法があります。パスワード、認証コード、秘密鍵は会話やログへ貼らず、必要な入力は正規の入力画面で本人が行います。Codexの承認表示や設定名は更新される可能性があるため、公開前に現行画面で※要確認です。

書き込み範囲と承認の違いを詳しく確認したい場合は、Codexのsandboxエラーを解決するも参照してください。

再試行前に条件を変える

再試行は、原因に対応する条件を1つ変えてから行います。同じ入力を同じ環境へ連続送信しても、同じ失敗を重ねるだけになりがちです。

• 待機なら、未回答の質問へ答える
• コマンドが無いなら、作業ディレクトリと実行環境を確認する
• 入力ファイルが無いなら、パスとファイル名を確認する
• 権限待ちなら、対象を狭めるか必要な承認を判断する
• 通信失敗なら、処理済みかを確認してから再送する

再試行後は「画面が進んだ」ではなく、終了コード、期待したファイル、テスト結果のいずれかで完了を確かめます。ファイル変更を伴う処理なら、更新時刻だけでなく差分も見ます。原因を2つ同時に変えると、どちらが効いたか分からなくなるため、一度に変える条件は原則1つです。

再実行のたびに対象が広がる場合は、Codexへの依頼テンプレートを使い、対象、完了条件、触らない範囲を固定してからやり直します。

再発防止ログを残す

直った後は、長い会話全体ではなく、次回の判断に必要な情報だけを残します。

- 発生日時: ※要確認
- 症状: 最後の出力が変わらなかった
- 分類: コマンド失敗
- 失敗した操作: ※要確認
- 終了コード: ※要確認
- 原因: ※要確認
- 変更した条件: ※要確認
- 再実行の結果: ※要確認
- 秘密情報の除去: 済み

「何となく再起動したら直った」では、次回も同じ調査が必要です。失敗した操作と、再試行前に変えた条件を対で残すと再利用できます。実際のCodexエラー文、発生日時、復旧までの所要時間は運用ログを確認できていないため、本下書きでは創作せず※要確認としています。

よくある質問

Codexが止まったら、まず再送してもよいですか

先に最後の出力と変更済みのファイルを確認します。処理が続いている状態で同じ指示を送ると二重実行になる可能性があるため、待機・失敗・権限待ちのどれかを仮分類してから再送します。

終了コード0なら、作業はすべて成功ですか

コマンドとしては成功扱いですが、期待した成果物まで正しいとは限りません。対象ファイル、差分、テスト結果など、依頼の完了条件も合わせて確認します。

標準エラーに文字が出たら失敗ですか

必ずしも失敗ではありません。ツールによっては警告や進捗を標準エラーへ出すため、終了コードと生成物を一緒に見ます。

権限の確認画面は許可すべきですか

操作対象、影響範囲、元へ戻せるかを読んで判断します。内容が不明なら許可せず、読み取りだけにする、対象を作業フォルダ内へ絞るなど、依頼を狭められます。

同じエラーは何回まで再試行すべきですか

固定の回数ではなく、原因に対応する条件を変えられたかで判断します。同じ条件のまま繰り返さず、作業ディレクトリ、パス、権限、入力のうち1点を確認・修正してから再試行します。

一次情報

確認日はいずれも2026-07-23です。

• OpenAI公式「Agent approvals & security」: https://learn.chatgpt.com/docs/agent-approvals-security
• OpenAI公式「Sandbox」: https://learn.chatgpt.com/docs/sandboxing
• Microsoft Learn「about_Automatic_Variables」: https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_automatic_variables
• The Open Group「Shell Command Language」: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html