Codexのエラー・動かない時の対処｜止まった時の確認順

Codexの作業が途中で止まった、画面が固まった、エラーが出たまま進まない。そんな時に、何から確かめればよいかをまとめました。OpenAIの公式資料には、ChatGPTデスクトップアプリでCodexを使う時のトラブル対処のページがあり、止まって見える時はまず「承認を待っていないか」「ターミナルで状態を確かめる」「依頼を小さく絞って新しいチャットを始める」の3つを見るよう書かれています。

この記事では、この3つの確かめ方に加えて、症状ごとの確認先、ターミナルや表示がおかしい時の戻し方、CLIでは動くのにアプリで動かない時の確かめ方、直らない時に集める情報と報告のしかたを説明します。Codexに自分のプログラムのエラーを直してもらいたい場合は、Codexでデバッグを頼む記事を見てください。

この記事は、OpenAIの公式資料に基づく解説です。参照したのは開発者向け資料のTroubleshooting、Command line options（codex doctorと/feedback）、Codex CLI、IDE拡張のスラッシュコマンド、Permissions、Integrated terminal、Code review、Settings、Commands、Worktrees、Local environments、Agent approvals & security、Advanced Configuration、Configuration Reference、Manage app updates、Windows appで、いずれも2026年11月4日に取得した版です。画面の名前と手順は公式資料の記載によるもので、編集部がCodexで不具合を再現した実測ではありません。症状の分け方と表の並べ方は編集部の整理です。

Codexが止まった時に最初に確かめる3つのこと

公式のTroubleshootingは、チャットが止まって見える時の確認として、次の3つを順に挙げています。エラーの文面を調べ始める前にこの3つを済ませると、壊れたのではなく待っていただけ、という場合を先に除けます。

1. Codexが承認を待っていないか

Codexは、決められた範囲を超える操作の前に止まって、承認を求めることがあります。公式のPermissionsによると、ふだんの作業に勧められている「Ask for approval」は、今の作業フォルダの中では進め、その外へ出る前に止まるモードです。また、公式のAgent approvals & securityによると、Codexは既定ではネット接続を切った状態で動きます。画面に確認の依頼が出ていないかを見てください。

デスクトップアプリで確認の依頼が開いている時は、Enterで承認、Escで断る操作になります（公式のCommandsのショートカット表）。慌ててEscを押すとその操作を断ったことになるので、依頼の中身を読んでから選びます。

2. ターミナルで今の状態を確かめる

デスクトップアプリのターミナルを開き、git statusのような基本のコマンドを実行します。ターミナルはCtrl+`（バッククォート）で開きます（公式のIntegrated terminal）。Commandsのショートカット表では、この操作はターミナルの開閉の切り替えで、macOSでも⌃（Control）のキーです。git statusではファイルの変更の状態を、pwdでは今いるフォルダを確かめられます。

3. 依頼を小さく絞って新しいチャットを始める

それでも進まない時は、依頼を小さく、焦点を絞って、新しいチャットで始め直します。作業の場所（Local・Worktree・Cloud）を選び間違えて始めた時は、実行を取り消してから入力欄で上矢印キーを押すと、前に書いた依頼文を呼び戻せます。worktreeの作成を誤って取り消して依頼文が消えた時も、入力欄で上矢印キーを押せば戻せます。

ターミナルが固まっている場合は次の節の手順で戻します。アプリの再起動は、公式資料のとおり、動いているチャットが終わるのを待ってから行います。

Codexの症状ごとに確認先を分ける

「Codexが動かない」と一口に言っても、インストールの直後に起動しない場合と、使っている途中で止まる場合では、見る場所が違います。次の表は、起こり得る症状ごとに、最初に確かめることと行き先を編集部がまとめたものです。Codexでの実測ではなく、各症状の詳しい確認順は行き先の記事で説明しています。

「急に起動しなくなった」の行は、公式のAgent approvals & securityに、廃止されたapproval_policy = "untrusted"が残っているとCodexが起動しないことがある、と書かれている内容です。「席を外すと止まる」の行の設定は公式のSettingsに載っています。ここから先は、どの機能でも起こり得る、デスクトップアプリで使っている途中のトラブルを扱います。

Codexのターミナルが固まった時の戻し方

デスクトップアプリの中のターミナルが反応しなくなった時の手順は、公式のTroubleshootingに次のように書かれています。

1. ターミナルのパネルを閉じる
2. Ctrl+`で開き直す
3. pwdやgit statusのような基本のコマンドを実行し直す

コマンドの動きが思っていたものと違う時は、まずターミナルの今のフォルダとブランチを確かめます。それでも固まったままなら、動いているチャットが終わるのを待ってから、アプリを再起動します。

ターミナルの表示を消すショートカットは、公式資料の間で書き方が分かれています。Commandsのショートカット表には、macOSでターミナルを選んでいる時の操作として「⌃+L」と「⌘+K」が載っています。一方、Integrated terminalのページは、⌘+Kはコマンドパレットを開く操作でターミナルは消さず、消すにはCtrl+Lを押すと書いています。編集部はどちらが正しいかを判定していません。両方の資料で一致しているのはCtrl+Lです。

Codexの表示や許可の画面が思っていたものと違う時

作業は進んでいるのに、表示や出てきた画面が思っていたものと違う、という場合の答えも公式資料のFAQに載っています。この節の話はデスクトップアプリでの例です。

Codexが触っていないファイルが変更の一覧に出る

プロジェクトがGitのリポジトリの中にある場合、変更を見るパネル（レビューのパネル）は、Codexの変更だけでなく、自分で編集した変更も含めて、まだコミットしていない変更をすべて表示します。Codexが触っていないファイルが出るのはこのためです。

直前のCodexの変更だけを見たい時は、表示を「Last turn」に切り替えます。公式のCode reviewによると、パネルの既定は「Unstaged」（まだステージしていない変更）で、ほかに「Staged」（ステージした変更）、「Commit」（選んだコミット）、「Branch」（基点のブランチとの差）に切り替えられます。Troubleshootingでは、ブランチをmainと比べられると書かれています。

会話が一覧に出ない・見つからない

サイドバーの会話の一覧は、プロジェクトの状態で絞り込めます。見当たらない会話がある時は、「Chats」の横の絞り込みのアイコンを選び、「Chronological」（時系列）に切り替えます。それでも出ない時は、Settingsの「Archived chats」を確かめます。アーカイブした会話はここに日付とプロジェクトの情報つきで並び、「Unarchive」で元の場所へ戻せます。

macOSで「ミュージック」などへのアクセスを求められる

作業の内容によっては、Codexがファイルの場所をたどることがあります。macOSでは「ミュージック」「ダウンロード」「デスクトップ」などのフォルダに、使う人の許可が別に必要で、Codexがホームフォルダを読む必要がある時にmacOSが許可を求めてきます。作業と関係のないフォルダなら、許可する前に依頼の範囲を見直してください。

CLIでは動くのにCodexアプリで動かない・機能が出ない時

ある機能がCodex CLIでは使えるのに、ChatGPTデスクトップアプリでは使えない、ということがあります。公式資料によると、デスクトップアプリとCLIには別の版のCodexが入っていることがあり、新しい機能が片方に先に届く場合があるためです。まず両方の版を比べます。

CLIの版は、ターミナルで次のコマンドで確かめます。

codex --version

macOSでアプリに入っているCodexの版は、公式資料が示す次のパスで確かめます。アプリはChatGPTデスクトップアプリになりましたが、互換のためにCodex.appの場所が残されています。Troubleshootingに載っているのは、このmacOSのパスだけです。

/Applications/Codex.app/Contents/Resources/codex --version

デスクトップアプリは、ふだんはアプリが自動で更新を確かめて入れます（公式のManage app updates）。会社がアプリの中の更新を止めている端末では、Settingsの「General」にある「In-app updates」に「Managed」と表示され、更新は管理者の配布を待つことになります。

CLIを新しくするコマンドは、入れた方式ごとに公式のCodex CLIに載っています。macOS・Linux・Windowsの公式のインストーラーとnpmは、インストールと同じコマンドをもう一度実行します。Homebrewで入れた場合だけ、更新は別のコマンドです。

brew upgrade --cask codex

「Approve for me」が出ない・選べない時

「Approve for me」は、確認の依頼を自動の審査に回すモードです。権限のモードは、デスクトップアプリとIDE拡張では入力欄の下の権限のメニューで、CLIでは/permissionsで切り替えます（公式のPermissions）。デスクトップアプリの権限のメニューに「Approve for me」がない、または選べない時の確認順は、公式資料に次のように書かれています。

1. デスクトップアプリを新しくし、使いたいチャットで権限のメニューを確かめる。選べるものは、自分のパソコンで動かす時とクラウドで動かす時で違うことがある
2. 自分のパソコンで動かしている場合は、実際に効いている設定にfeatures.guardian_approval = falseが書かれていないかを見て、権限のプロファイル、承認の方針、承認の審査役の設定も確かめる
3. 会社で管理されたワークスペースなら、管理者に、許可されている権限のプロファイル、サンドボックスの方式、承認の方針、審査役を確かめてもらう。組織や端末の方針は、自分の設定では変えられない

2のfeatures.guardian_approvalは、公式のConfiguration Referenceでは、管理者が管理対象の利用者向けに固定するrequirements.tomlの項目としてだけ載っています。Troubleshootingの書き方と扱いが分かれており、編集部はどちらが正しいかを判定していません。自分でconfig.tomlにこのキーを書き足したり変えたりせず、見つけた時は管理者に確かめてください。会社で管理されていない端末なら、次の段落のとおりフィードバックで報告します。

それでも出ない時は、アプリの版、OS、実行している環境、そして「出ない」のか「選べない」のかを、フィードバックに書き添えるよう公式資料は案内しています。各モードの違いはスラッシュコマンドの記事の/permissionsの節で説明しています。

Codexのプロジェクト設定が読まれない・worktreeで動かない時

プロジェクトの準備に関わるトラブルも、公式資料のFAQに載っています。詳しい設定はそれぞれの記事に任せ、ここでは原因の見当をつけるところまでを書きます。

• worktreeでコードが動かない：worktreeは別のフォルダに作られ、既定ではGitで管理しているファイルを引き継ぎます。依存関係の準備はローカル環境のセットアップで動かします。Gitで無視している設定ファイル（.envなど）は、リポジトリの一番上の.worktreeincludeに書くと、Codexが管理する手元のworktreeへ写されます。Gitで無視していないだけの、追跡していないファイルは写されません（公式のWorktrees）。詳しくはWorktreeの実行環境の用意とローカル環境の確認順で説明しています。
• チームで共有したローカル環境が読まれない：公式のLocal environmentsによると、ローカル環境の設定は、プロジェクトの一番上にある.codexフォルダに入っている必要があります。1つのリポジトリに複数のプロジェクトがある場合は、.codexフォルダがあるフォルダを開きます。
• スケジュールした作業でworktreeが増え続ける：頻繁に動くスケジュールは、時間がたつとworktreeが増えます。いらなくなった実行はアーカイブし、残す必要がない実行はピン留めしないようにします。登録のしかたはスケジュールの記事で説明しています。

Codexの不具合が直らない時に集める情報と報告のしかた

ここまで確かめても直らない時は、状況をまとめて開発元に報告できます。報告の前に集めておく情報と、その場所を公式資料から整理します。なお、公式のTroubleshootingは、再インストールや設定のフォルダを消すことを対処として挙げていません。

1. CLIならcodex doctorで診断レポートを作る

公式のCommand line optionsによると、codex doctorは、サポートへの報告の前や、インストールが壊れた時の調査に使う診断レポートを作るCLIのコマンドです。インストール、設定、認証、実行環境、Git、ターミナル、app-server、会話の一覧の状態を調べます。

codex doctor

2. 使っている入口からフィードバックを送る

フィードバックは/feedbackで送ります。公式のAdvanced Configurationによると、/feedbackはデスクトップアプリ・CLI・IDE拡張に共通です。デスクトップアプリでは、入力欄で「/」を入力してフィードバックを送ります（公式のTroubleshooting）。いま開いているチャットから送る場合は、そのセッションを一緒に共有するかを選べます。送ったあとにセッションのIDが表示されるので、問い合わせの時に伝えられるよう控えておきます。CLIでは案内に沿ってログや診断の情報を添えられ、IDE拡張でもログを添えられます（公式のIDE拡張のスラッシュコマンド）。

公式のAdvanced Configurationによると、設定で[feedback]のenabled = falseにすると、その端末のデスクトップアプリ・CLI・IDE拡張でフィードバックが無効になり、/feedbackは無効の表示になります。会社の端末で送れない時は、管理者に確かめてください。

3. ログの場所を確かめ、中身を見てから渡す

公式資料が示すログの場所は次のとおりです。

アプリのログの場所は、公式資料にはmacOSの分だけが載っています。Windowsのアプリは、Codexのホームとして%USERPROFILE%\.codexを使うと公式のWindows appに書かれています。

公式資料は、ログを渡す前に中身を見て、機密の情報が入っていないかを確かめるよう書いています。パスワードやAPIキーのような値が見えたら、その部分を消してから渡してください。

4. GitHubで同じ報告がないかを探してから出す

公式資料は、まずCodexのGitHubリポジトリのIssueで同じ問題がすでに報告されていないかを探し、なければ新しいIssueを作るよう案内しています。公式資料の新しいIssueへのリンクは、不具合報告（bug report）の書式を開きます。

報告の文面には、インストールの記事の「相談するときのメモ」の項目（OS、導入方法、版、エラー文など）に加えて、使っている途中の不具合では次の項目を足すと状況が伝わりやすくなります。項目は公式資料が挙げる情報をもとに、編集部がまとめた例です。

使っている入口：ChatGPTデスクトップアプリ / CLI / IDE拡張 / Cloud
アプリの版と、アプリに入っているCodexの版：
作業の場所：Local / Worktree / Cloud
止まった場面：作業中 / 承認の依頼 / 結果の確認 / ターミナル
メニューの項目：出ない / 出るが選べない
フィードバックを送った後のセッションのID：
見たログの場所：

Codexを社内で使う時は止まった時の一次対応と報告の型を決める

会社で管理されたワークスペースでは、使う人が自分で変えられることに限りがあります。「Approve for me」のようなモードは組織や端末の方針で制限されることがあり、アプリの更新やフィードバックも管理者が止めている場合があります。ネット接続を許可したはずの操作が止められる時に、方針の優先順位から確かめる手順は、公式のTroubleshootingの最後の節に管理者向けにまとめられています。

社内でCodexを広げる時は、止まった時に使う人が自分で確かめる範囲（この記事の最初の3つ、ターミナル、表示、版）と、管理者へ渡す範囲（方針、更新、フィードバックの可否）を先に分け、報告に添える項目を決めておくと、問い合わせを片付けやすくなります。広げる前に止める条件と戻し方を決める考え方は、Codexの法人導入の記事で説明しています。Codex Studioを運営する株式会社PLaiでは、法人向けにCodexの導入と研修の相談を受けています。

まとめ：Codexが止まったら、待っているのか、どこで止まったのかを見分ける

• 止まって見える時は、承認を待っていないか、ターミナルのgit status、依頼を小さく絞った新しいチャット、の順に確かめる
• インストール直後に起動しない問題と、使っている途中で止まる問題は確認先が違う。機能ごとの不具合は、症状別の表から各記事の確認順へ進む
• ターミナルが固まったら、閉じて開き直し、基本のコマンドを打ち直す。直らなければ、動いているチャットが終わってからアプリを再起動する
• CLIでは動くのにアプリで動かない時は、両方の版を比べる。「Approve for me」が出ない時は、アプリの更新、自分の設定、管理者の方針の順に確かめる
• 直らない時は、codex doctor・フィードバック・ログ・GitHubのIssueで報告する。ログは中身を見て、秘密の値を消してから渡す