Codexで認証エラーが出たときの最短復旧7手順

昨日まで動いていたのに、急にCodexが止まり、認証エラーで何も進まなくなる。いちばんつらいのは、原因が自分の設定ミスなのか、一時的な不具合なのか、画面を見ただけでは判断しにくいことです。
この症状は、いま使っている認証情報が無効になった、ログインの更新が途中で失敗した、接続先や設定ファイルがずれている、このどれかで起きることがほとんどです。順番を間違えずに確認すれば、遠回りせず復旧できます。
最初にやることは難しくありません。ログアウトして再ログイン、保存済みの認証情報を入れ直す、設定ファイルと環境変数を見直す。この3つで、多くのケースはその日のうちに動き出します。

まず知っておきたい症状の正体

Codexで認証エラーが出る場面は、大きく2つあります。ひとつは、起動直後や実行直前に止まるパターン。もうひとつは、しばらく使っていたのに途中から急に止まるパターンです。
前者は、保存済みの認証情報がすでに使えないケースが多めです。後者は、古い認証情報を新しいものへ切り替える途中で失敗したケースが目立ちます。実際、最近のCodex関連では、トークン更新まわりで認証失敗が起きる報告や、401で再接続が尽きる不具合報告が続いています。GitHub+2GitHub+2
さらに、直近ではCodex側で一部モデルの不具合や、認証失敗を含む障害が発生してから復旧した記録もあります。いま現在の全体ステータスが正常でも、少し前まで不安定だった可能性はあります。だからこそ、自分の設定だけを疑って深追いしないことが大切です。GitHub+3OpenAI Status+3OpenAI Status+3

最短で直す7手順

いちばん失敗しにくい順番は、下の流れです。上から順に試すと、無駄な設定変更を減らせます。

いちばん先に試す操作

ターミナルでCodexを使っているなら、いちばん先にやる操作はシンプルです。Codexを閉じて、ログアウトし、もう一度ログインし直します。
この流れで大事なのは、再ログインの前に必ず古い認証状態を外すことです。ログインだけを重ねると、見た目は成功しても、裏で古い認証ファイルを参照し続けることがあります。
画面上では、再ログイン後にサインイン完了が表示され、ターミナルへ戻ったあとに通常どおりコマンドが進めば復旧です。逆に、再ログイン直後でもすぐ401になるなら、認証情報以外のずれを疑います。

ブラウザが開かないときの対処

社内PC、SSH先、WSL、リモートサーバーでは、ブラウザが開かない、開いても戻り先で止まる、という詰まり方が起きます。
この場面では、ブラウザ方式にこだわらず、デバイスコード認証へ切り替えるのが近道です。画面に表示されたコードを別のブラウザで入力できるため、ローカルの戻り先が使えない環境でも通しやすくなります。OpenAI開発者
もし別マシンで先に認証できるなら、認証済みのauth.jsonを使う方法もあります。ただし、このファイルは実質的に鍵なので、扱いはパスワードと同じです。共有フォルダへ置きっぱなしにしたり、チャットへ貼ったりしないよう注意が必要です。OpenAI開発者

再ログインでも直らないときの確認ポイント

設定ファイルの場所が合っているか

Azure経由でCodexを使う場合、設定ファイルは~/.codex/config.tomlに置きます。別のフォルダに作っても読み込まれません。ファイルを修正したあとに新しいターミナルを開かず、古いセッションのまま試しているケースもよくあります。
画面上で確認しやすい目安は、設定変更後に新しいターミナルで起動したときだけ挙動が変わるかどうかです。変わらないなら、編集したファイルが違うか、読み込む前提の環境変数が入っていない可能性があります。

環境変数の名前と値を取り違えていないか

初心者が非常にハマりやすいのがここです。設定ファイルへ直接キー文字列を書いたつもりでも、期待されているのはキーそのものではなく、環境変数名だった、というケースです。
Azure構成では、env_keyには環境変数名を入れる前提になっており、さらにv1のResponsesAPIではbase_url側に/v1が必要です。この2つがずれると、認証情報が正しくても401や接続失敗に見えることがあります。Microsoft Learn

古いセッションが生き残っていないか

認証をやり直したのに、開きっぱなしのCodexセッションだけ失敗し続けることがあります。これは、新しい認証情報を取りにいかず、古いセッションが古い状態のまま動いているためです。最近も、外でログインし直しても既存のライブセッションが継続できない不具合報告が出ています。
この場合は、ターミナルを閉じるだけでなく、関連するセッションやエディタの拡張機能もいったん終了し、完全に開き直したほうが早く直ります。

画面別に見る、失敗しやすいポイント

CLIでは直ったのにVSCode側だけ止まる

CLIが使えるのに拡張機能だけ読み込み中のままなら、拡張機能側のキャッシュや設定が残っている可能性があります。こういうときは、CLIの再ログインだけで終わりにしないことが重要です。
拡張機能を閉じても直らないなら、Codex関連のキャッシュや設定を整理してから起動し直します。特にWindowsやVSCodeでは、古い状態が残ってログイン画面自体が出ないことがあります。OpenAI Developer Community

Missingbearerのような表示が出る

これは、認証ヘッダーが送れていない、または途中で消えている状態です。感覚的には「鍵が無いままドアを開けようとしている」状態です。
このタイプは、トークン期限切れだけでなく、接続先の設定ずれや代理経由の処理でヘッダーが落ちる場面でも起きます。最近の外部ワークフロー失敗報告でも、Missingbearer系の401が複数見られます。ローカルの再ログインで直らないなら、接続経路や実行環境も確認対象です。GitHub+1

Codex認証エラーに関する疑問解決

「急に出たからOpenAI側の全面障害だ」と決めつけるのも危険ですし、「全部自分の設定ミスだ」と思い込むのも遠回りです。切り分けのコツは、再ログインだけで直るか、別の実行環境でも同じか、全体ステータスに異常があるかの3点を同じ日に確認することです。
判断に迷ったら、下の表の見方で進めると混乱しにくくなります。

症状	まず疑うこと	最初の一手
起動直後から401で止まる	保存済み認証の失効	ログアウト後に再ログインする
しばらく使えたのに途中で止まる	更新処理の失敗、古いセッション残り	開いているセッションを全部閉じて認証し直す
Azure構成だけ失敗する	config.tomlや環境変数のずれ	base_urlとenv_keyを見直す
CLIは動くがVSCodeだけ止まる	拡張機能側のキャッシュ残り	拡張機能を再起動し、必要なら関連キャッシュを整理する
自分は失敗するが全体でも不安定そう	サービス側の一時的不具合	状態を確認し、復旧後に再試行する

初心者が最初につまずく落とし穴

ログアウトできたつもりで、古い状態のまま進めてしまう

Codexの画面やターミナルを開いたまま、別のターミナルで再ログインだけ済ませて、「よし、これで直ったはず」と思ってもう一度実行したのに、また同じ認証エラーが出る。この場面、かなり多いです。特に、VSCodeのターミナル、通常のターミナル、拡張機能の画面が同時に開いていると、どれが今の認証状態を使っているのか分からなくなります。
なぜそうなるのかというと、再ログインしても、すでに開いている古いセッションが新しい認証情報を自動で取り直さないことがあるからです。感覚的には、古い入館証を首から下げたまま、新しい入館証をポケットに入れている状態です。持ってはいるのに、実際に見せているのは古いほうです。
こうすれば一発で解決します。

ブラウザ認証の途中で止まり、何を待てばいいのか分からなくなる

ログイン操作をするとブラウザが開く。でも、サインインしたあとに元の画面へ戻らない。ターミナルには何も増えない。初心者だと「固まった？」「失敗？」「もう一回押す？」となりやすい場面です。ここで何度も同じ操作を重ねると、かえってややこしくなります。
原因はシンプルで、ブラウザ側では認証できていても、ターミナル側がその完了を受け取れていないことがあります。これは、社内PC、別ブラウザ、ポップアップ制限、戻り先の受け渡し失敗で起こりやすいです。トークン（本人確認の通行証のようなもの）が発行されても、手元の画面まで届いていないイメージです。
こうすれば一発で解決します。

設定ファイルを直したのに、反映されたのか判断できない

設定ファイルを開いて、必要そうな箇所を直した。保存もした。なのに結果が何も変わらない。初心者がいちばん心が折れやすいのがこの場面です。「保存できていない？」「場所が違う？」「書き方が違う？」と不安が一気に増えます。
こうなる原因は、だいたい3つです。ファイルの保存場所が違う、環境変数（設定値を一時的に持たせる名札のようなもの）が古いまま、変更後も古いターミナルを使っている。この3つは見た目では区別しにくいので、順番を決めて確認したほうが早いです。
こうすれば一発で解決します。

「知っている」と「できる」の差を埋める実践ロードマップ

最初の7日間は、難しいことを増やさず、毎日1個だけ確認するほうが伸びます。初心者が途中で止まる理由の8割は、やることを一気に増やしすぎるからです。だから、1日15分から30分で終わる形に分けます。大事なのは、毎日「何を触れば前進したと言えるか」が自分で分かることです。

1日目:今の認証状態を見える化する

やる作業は15分です。ターミナルを1つだけ開いて、Codexを起動します。起動できたら、今の状態が正常か、エラーかをメモします。エラーが出たら、その文言を丸ごと保存します。短く省略せず、1文字違わず残すのが大事です。
完了の判断基準は明確です。「正常に起動した」か「どの文言で止まったか」が1行で説明できたらOKです。ここで「なんかダメだった」で終わると、2日目以降が全部ぼやけます。

2日目:ログアウトと再ログインを自力で1回通す

やる作業は20分です。昨日使ったのと同じ環境で、ログアウトしてから再ログインします。ブラウザ方式で進めて、最後にターミナルへ戻って結果を確認します。
この日のゴールは、ログアウト完了表示とログイン完了表示の両方を自分で確認できることです。正常に終わったら、「どの画面が出て、どこで待つか」が頭に入ります。ここが分かるだけで、次に止まっても慌てにくくなります。

3日目:ブラウザ方式がだめなときの代替手段を試す

やる作業は25分です。デバイスコード方式のログインを一度だけ試します。普段ブラウザ方式で問題なく使えていても、1回経験しておく価値があります。なぜなら、社内PC、別端末、リモート接続の場面で急に必要になるからです。
完了の判断基準は、表示されたコードを別画面で入力し、元のターミナルで認証完了表示を見られたらOKです。これができると、ブラウザが開かない場面でも止まりません。

4日目:設定ファイルと環境変数の場所を確認する

やる作業は30分です。設定ファイルを開いて、保存場所を確認します。次に、ターミナルで必要な環境変数を入れたあと、Codexを起動します。ここでは「値を完璧に理解する」より、どこを触ると反映されるかをつかむのが目的です。
完了の判断基準は、設定ファイルの場所を自分の言葉で説明できて、新しいターミナルを開いたときだけ変更が反映されることを確認できたらOKです。

5日目:わざと1回だけ失敗させ、復旧手順を練習する

やる作業は20分です。ここは少し実戦寄りです。いきなり本番で止まると焦るので、短い作業を実行して、もしエラーが出たら昨日までの手順で戻します。ポイントは、長い処理や本番データではなく、すぐ終わる軽い実行で試すことです。
完了の判断基準は、止まったあと10分以内に、ログアウト、再ログイン、新しいターミナルで再実行までできたらOKです。これができると、「知ってるだけ」から「戻せる」に変わります。

6日目:自分専用の復旧メモを3行で作る

やる作業は15分です。今までの流れを、自分用に3行だけ残します。たとえば、「まず全部閉じる」「次に認証やり直し」「最後に新しいターミナルで確認」のように、順番だけを残します。長いメモは、止まったときに読み返しません。
完了の判断基準は、3行を見れば、次に止まっても2分以内に動き始められる状態になったらOKです。

7日目:本番に近い環境で1回通す

やる作業は30分です。普段使う環境で、実際にCodexを起動して、短い1回の実行を最後まで通します。VSCodeを使うならVSCodeで、ターミナル中心ならそのままで構いません。大事なのは、自分が本当に使う場所で確認することです。
完了の判断基準は、起動、認証、1回の実行、終了までが同じ環境で止まらず完了したらOKです。これで「いつかできそう」ではなく、「今日から使える」に変わります。

現実でよくある「あるある失敗」と専門家の対処法

失敗その1:エラーが怖くて、同じコマンドを5回連打してしまう

よくあるのがこれです。1回目で401が出る。焦ってもう一度押す。変わらないのでさらに押す。数分後には、どの操作の結果が今の画面なのか自分でも分からなくなります。初心者ほど、「止まっている時間が怖い」ので、手を動かし続けてしまいます。
根本原因は、1回の失敗を確認する前に次の操作を重ねてしまうことです。認証エラーは、連打しても突破できる種類ではありません。むしろ、古いセッションや中途半端な認証状態が増えて、切り分けが難しくなります。
専門家ならこう対処します。まず、その場で手を止めます。次に、最後に表示されたエラー文言を1回だけ確認します。そのあと、開いているCodex関連の画面を全部閉じます。そして、新しいターミナルを1本だけ開いて、ログアウト、再ログイン、再実行の順でやります。同時に触る画面は1つだけ。これだけで、混乱の8割は消えます。
予防策は簡単です。同じ失敗が2回続いたら、3回目を打つ前に必ず全画面を閉じると決めておくことです。回数でルール化すると、焦っていても止まりやすいです。

失敗その2:CLIでは動くのに、VSCodeでは動かないまま数時間悩む

ターミナルでは正常に起動できた。なのに、VSCode側だけ読み込み中のまま、または認証が終わらない。このとき初心者は「さっき認証したのに、なんで？」となります。感覚的には同じCodexに見えるので、余計に混乱します。
根本原因は、CLIと拡張機能が同じ見た目でも、内部では別の状態を持つことがあるからです。たとえるなら、同じ建物の1階受付と2階受付で、別々に入館記録を見ている感じです。1階で通れても、2階で古い記録を見て止められることがあります。
専門家ならこう対処します。まず、CLIで動くことを確認できたら、VSCode側の問題だと切り分けます。次に、VSCodeを完全に終了します。ウィンドウを閉じるだけでなく、裏で残っていないか確認します。そのあと、Codex関連のターミナルも閉じます。さらに新しくVSCodeを開き、最初の1回だけ短い処理を流します。これで戻れば、問題は拡張機能側の古い状態だったと判断できます。
予防策は、認証をやり直した日は、VSCodeも1回閉じてから開き直すことです。たった30秒ですが、これを挟むだけで無駄な1時間を防げます。

失敗その3:設定ファイルを直したあと、古いターミナルでそのまま試してしまう

これは本当に多いです。設定ファイルを保存して、「よし直した」と思って、さっきから開いていたターミナルでそのまま再実行する。でも挙動が変わらない。すると「設定が間違ってる」と思い、さらに別の場所までいじり始めて泥沼になります。
根本原因は、環境変数や設定の読み込みが、ターミナルを開いた時点の状態に固定されていることがあるからです。つまり、ファイルを直しても、その場にいる古いターミナルは昔の情報のままです。
専門家ならこう対処します。設定ファイルを直したら、その時点で古いターミナルを閉じます。次に、新しいターミナルを開きます。必要な環境変数を入れ直します。そのあとでCodexを起動します。これで変化が出れば、設定変更は正しくできていたと判断できます。ここを飛ばしてしまうと、正しく直した設定まで「間違い扱い」してしまいます。
予防策は、設定ファイルを1回でも直したら、新しいターミナルでしか再確認しないと決めることです。ルールにしてしまうと迷いません。

ぶっちゃけこうした方がいい！

正直に言うと、初心者のうちは「原因を完璧に理解してから動く」より、「戻し方を先に体で覚える」ほうが圧倒的に早いです。認証エラーって、仕組みを深く読むほど偉いわけではありません。最初に必要なのは、止まったら10分で復旧ラインに戻せることです。ここさえできれば、学びながら前に進めます。
ぶっちゃけ、最初は設定の細かい意味を全部覚えなくていいです。base_urlがどうとか、環境変数がどうとか、もちろん大事です。でも、最初の段階でそこを全部理解しようとすると、知識が増える前に手が止まります。まず集中すべきなのは3つだけです。全部閉じる、認証をやり直す、新しいターミナルで試す。この3手が最重要です。
あと、ぶっちゃけ最初はVSCodeとCLIを同時に育てなくていいです。どっちも触ると、問題が起きたときに切り分けが一気に難しくなります。最初の1週間はCLIだけで十分です。CLIで1回でも自力復旧できたら、そのあとでVSCodeへ広げればOKです。順番を逆にすると、見た目が便利な分だけ混乱しやすいです。
もうひとつ本音を言うと、初心者がいちばん時間を溶かすのは、「たぶんこうだろう」で触り続けることです。だから、止まったときは意地で続けないほうがいいです。2回失敗したら手順に戻る。これを徹底した人のほうが、結果的に上達が早いです。感覚で直そうとするより、同じ復旧手順を3回繰り返した人のほうが強いです。
最短で結果を出したいなら、今日やることは多くありません。まず、ターミナルを1本だけ開く。次に、ログアウトと再ログインを通す。最後に、短い1回の実行だけ確認する。長い処理や本番作業は、そのあとでいいです。大きい作業から始めると、止まったときに原因が増えます。小さい成功を先に作ったほうが、復旧も成長も速いです。
「〇〇の場面で、□□をすると、△△の結果になる」という形で言い切るなら、こうです。認証エラーの場面で、開いている画面を全部閉じてから再ログインすると、古い状態を引きずらずに新しい認証へ切り替えやすくなる。設定を直した場面で、新しいターミナルを開いてから再実行すると、変更が反映されたかどうかを正しく判断できる。CLIだけで先に1回通すと、VSCodeの問題をあとから落ち着いて切り分けられる。これが、最初のうちのいちばんコスパがいい進め方です。
最後にひとつだけ。初心者のうちは、「1回で直せる人」より「同じ順番で毎回戻せる人」のほうが、あとで強くなります。だから、完璧さより再現性です。今日から意識するのは、才能でもセンスでもなく、復旧手順を毎回同じ順番でやること。それだけで、認証エラーに振り回される時間はかなり減ります。

よくある質問

ログアウトして再ログインするだけで、本当に直る？

直ることはかなり多いです。とくに、前日まで使えていて急に401になった場合は、認証情報の更新に失敗しているだけのことがあります。ログイン情報をいったん空にしてから取り直すと、すんなり戻ることがあります。トークン更新失敗の報告や、既存セッションが新しい認証へ追従しない報告とも一致します。

再ログイン後も同じエラーなら、何を疑うべき？

まずは設定ファイルの場所、環境変数名、base_urlの書き方です。Azure経由では、この3つのどれかがずれているだけで認証失敗に見えます。次に、開きっぱなしのセッションや拡張機能が古い認証状態を持ち続けていないか確認します。

社内PCやリモート環境でブラウザ認証ができないときは？

その場で悩み続けるより、デバイスコード認証へ切り替えるのが早いです。画面に出たコードを別ブラウザで入力する方式なので、戻り先のローカル接続が使えない環境でも通しやすくなります。

401が出た日は、待ったほうがいい？それとも設定を直すべき？

最初の10分は、自分で直せるところを先に試すのがおすすめです。ログアウト、再ログイン、セッション再起動、設定確認までやっても直らないなら、その日はサービス側の不安定さも視野に入れます。直近でもCodex関連の不具合や認証失敗は断続的に起きており、現在正常でも少し前に問題が出ていた日があります。

まとめ

Codexの認証エラーは、見た目のわりに対処の順番がはっきりしています。まずはログアウトして再ログイン。次に開いている古いセッションを閉じる。それでも直らなければ、~/.codexの設定と環境変数を確認する。この順番なら、余計な変更を増やさずに復旧しやすくなります。
今日すぐ動くなら、最初の一歩は迷わなくて大丈夫です。いま止まっているターミナルを閉じて、認証を入れ直し、必要ならデバイスコード認証へ切り替える。そこまでやってから設定ファイルを見る。この順番で進めれば、かなりの確率で前に進めます。