Codex停止できない時の対処法と変更ファイルの確認手順

10月の修正情報を踏まえて停止状態を見直す

OpenAIの公式更新情報では、2026年10月8日のアプリ更新について、待機中のメッセージが「Sending」に留まる問題と、別ウィンドウでのSteerに関する修正が案内されています。停止できないように見える場面では、作業そのものの進行と、メッセージの送信状態を分けて見る必要があります。更新情報は確認の手掛かりになりますが、手元の現象がその修正対象だと断定する根拠にはなりません。

例えば、依頼の送信表示だけが残っている場合と、端末に同じ出力が続いている場合では、記録すべき情報が異なります。前者なら送信表示と直前の操作、後者なら最後に動いていたコマンドと出力を残します。「停止できない」という一つの説明を、画面上で確認できる事実に分解することが復旧の出発点です。本記事では一定秒数で必ず止まるとは扱わず、表示の変化と作業場所の状態を判断材料にします。

停止できないときは待機と停滞を切り分ける

公式のアプリの不具合対処では、チャットが止まったように見える場合に、承認待ちの確認、基本的な端末操作の確認、小さく絞った依頼による新しいチャットを挙げています。これは、見た目だけでアプリ全体の故障を決めつけず、操作できる場所を調べるための確認です。停止を試した直後も、承認の表示や回答欄が残っていないかを確認すると、単に入力待ちなのかを見分けやすくなります。

確認中は同じ停止操作や依頼を連続して重ねるより、一回の操作に対して何が変わったかを記録します。表示が変わらない、入力欄は使える、別のチャットは開ける、といった観察結果は別々に扱います。入力できることだけでは実行中の処理が終わった証拠になりませんし、応答が遅いことだけでは変更が続いている証拠にもなりません。判断できない部分を残したまま、次の確認に進む姿勢が大切です。

Step 1: 対象チャットと最後の操作を確かめる

停止したいチャットを開き、対象のプロジェクト、最後に送った依頼、現在の表示を確認します。別のウィンドウや似た名前のチャットを見ていないかも確かめましょう。停止操作をした時刻と、その後に表示が変化したかを短く記録すると、後でアプリを開き直しても状態を比較できます。複数の作業がある場合は、それぞれを混同しないように対象を一つに絞ります。

Step 2: 承認や質問への回答待ちを探す

承認の選択肢、確認メッセージ、回答が必要な質問が出ていないかを見ます。確認画面があれば、操作対象と変更内容を読んでから許可するか判断します。復旧のためという理由だけで権限を広げる必要はありません。内容が分からない承認は保留し、何を待っているのかを記録します。待機を解消した後に進む場合も、元の依頼の範囲で動いているかを確認します。

Step 3: 送信待ちと実行中の表示を区別する

未送信または送信途中のメッセージが残っているなら、同じ文章をもう一度送る前にその状態を確認します。送信の問題と、すでに始まった作業の問題を混ぜると、復旧後に同じ依頼が重なる可能性を判断しにくくなります。更新前後で挙動を比較する場合は、アプリの版と発生条件を残しましょう。10月の修正情報だけを根拠に、未確認の状態を解消済みと扱わないことが重要です。

端末だけが応答しない場合の確認手順

画面の会話は開けるのに端末だけが反応しないなら、端末の表示と実際の作業場所を確認します。公式の不具合対処には、端末パネルを閉じて開き直し、基本的なコマンドを試す方法が載っています。ただし、パネルを閉じたことを、そこから始めたすべての処理が終了した証拠として扱わないでください。表示が戻った後も、元の処理については出力や状態を別に確認する必要があります。

ここでの目的は、同じ作業を別の場所で始め直すことではなく、操作の窓口が応答するかを確かめることです。現在のフォルダを確かめずにコマンドを打つと、違うプロジェクトの状態を見て復旧したと誤解することがあります。基本的な確認ができたら、変更一覧と照合して、対象チャットが扱っていた場所を見ているかを確かめます。読み取りの確認を先に済ませると、復旧操作そのものが新しい変更を作るのを避けられます。

Step 4: パネルを開き直して作業場所を確認する

端末パネルを閉じ、アプリの端末表示操作から開き直します。新たに入力できる端末で、現在のフォルダを確認してください。WindowsのPowerShellならGet-Location、一般的なUnix系の端末ならpwdが確認に使えます。既存の入力欄で別の処理が動いている可能性がある場合は、そこへ新しい文字を送り込まず、入力先が空いているかを確かめてから進みます。

Step 5: 読み取りのコマンドで応答を確かめる

Gitで管理している対象フォルダなら、git statusで状態を確認します。続いてgit diffで未確定の変更内容を読みます。出力が返れば、その端末で基本的な確認ができると分かりますが、元のチャットの停止完了まで証明するものではありません。エラーが出た場合は、エラー文と作業場所を記録します。対象がGit管理外なら、エディタでファイルを開いて更新内容を確認する方法を選びます。

再起動より先に変更ファイルを保全する

停止を押しても、すでに書かれた変更が元に戻ったとは限りません。復旧作業では、会話履歴、作業フォルダ、ファイルの差分を別々に確かめます。公式の不具合対処は、Git管理のプロジェクトではレビュー欄にCodexが行っていない変更も表示されると説明しています。したがって、変更一覧にあるという理由だけで、すべてを今回の不調に伴う編集だと判断することはできません。

自分が作業前から編集していた内容、直前の依頼で生じた内容、どちらか分からない内容を分けて見ます。判断できないファイルは、そのまま保全してから調べる方が確実です。プロジェクト全体を一括して元に戻す操作は、今回の問題と関係のない編集まで失う原因になり得ます。停止と取り消しを同じ操作として扱わず、残す内容が確定してから変更ごとに判断しましょう。

Step 6: 未確定の編集と新規ファイルを残す

変更されたファイルを別の保存先へコピーするなど、後から比較できる形で保全します。差分を保存する場合も、新規ファイルが含まれるかを別途確認してください。git diffの出力だけで、まだ追跡されていないファイルの内容まで残るとは限りません。保存先へ必要なファイルがそろったことを確かめてから、再起動や取り消しを検討します。保存した内容に私的な情報が含まれる場合は、共有せず手元で管理します。

小さな依頼で復旧を確かめてから再開する

公式の不具合対処は、停滞したチャットへの対応として、小さく絞った依頼で新しいチャットを始める方法を挙げています。また、端末の不調が続く場合のアプリ再起動については、ほかの実行中チャットが完了してから行う案内です。再起動を試す前に、今回の対象以外にも作業が動いていないかを確認しましょう。ウィンドウを閉じただけで、関連する作業がすべて止まったと判断しないことも大切です。

新しいチャットが応答しても、前の作業が停止したか、変更が正しいかは別の確認事項です。まず読み取りだけの依頼を使い、応答と対象フォルダが期待どおりかを見ます。停止状態を確認できない作業が残る間は、同じファイルへ新たな編集を依頼しない方が整理しやすくなります。再開時には、前回の未完了部分と今回許可する範囲を文章で示してください。

Step 7: 読み取りだけの依頼から試す

新しいチャットでは「このフォルダの構成を説明してください。ファイルは変更しないでください」のように、小さな確認を依頼します。対象フォルダ、回答内容、変更一覧を照合し、意図しない編集が増えていないかも確認します。応答が正常なら、次は一つのファイルや一つの不具合に範囲を限定します。途中までの成果物を確認せずに、元の大きな依頼をそのまま重ねないようにします。

Step 8: 解消しなければ事実をまとめて報告する

発生時のアプリの版、OS、Local・Worktree・Cloudのどこで起きたか、最後の操作、表示された文言をまとめます。公式の不具合対処には、入力欄からフィードバックを送る方法と、既存の問題報告を確認する案内があります。画面や記録を共有する前に、仕事の内容や個人情報が写っていないかを確認します。「止まらない」だけでなく、確認できたことと未確認のことを分けて伝えると、再現条件が明確になります。

停止できない状態を繰り返さないための依頼の区切り方

作業を再開するときは、依頼の完了条件を短く定めると途中経過を判断しやすくなります。例えば「このエラーの原因候補を調べる」「対象ファイルだけを修正する」「結果を確認する」を別々の依頼にすれば、どの段階で止まったかを説明できます。長時間待ったかどうかより、最後に完了した確認と、その後に始めた処理を区別できることが重要です。

依頼前には、自分の未確定の編集と作業場所を把握しておきます。依頼後は変更一覧を見て、想定した範囲の作業だったかを確かめます。これはCodexの不具合を必ず防ぐ方法ではありませんが、停止や表示の問題が起きたときに、残すべき成果物と再依頼する範囲を判断する助けになります。復旧の目標は画面が動くことだけでなく、変更を確認し、続けてよい状態を自分で説明できることです。