codex 401で詰まった人へ、ログイン地獄を抜ける確認ポイント
「codex 401」と検索している人の多くは、Codex CLI、VS Code / Cursor拡張、Codex App、MCP連携、APIキー利用のどこかで、401 Unauthorized や stream error: exceeded retry limit, last status: 401 Unauthorized にぶつかっているはずです。画面上は同じ401でも、実際には「ChatGPTログインの認証情報が古い」「APIキー権限が足りない」「プロバイダー設定が混ざっている」「MCP側の認可が切れている」など、原因がいくつかに分かれます。
この記事では、OpenAI Developer Community、GitHub Issues、Vercel Community、Figma Forumなどで確認できる事例をもとに、codex 401の見方、よくある原因、再ログイン・auth.json退避・APIキー権限・環境変数・MCP再認証までを整理します。体験談ではなく、公開されている事例を横断して「まずどこを見るべきか」がわかる形にまとめます。
| この記事のポイント |
|---|
| ✅ codex 401で最初に確認すべき場所 |
| ✅ 401エラーとは何か、なぜ起きるのか |
| ✅ ChatGPTログインとAPIキー利用で対処が違う理由 |
| ✅ VS Code / Cursor / Codex App / MCP / 外部プロバイダー別の切り分け方 |
codex 401でまず疑う認証まわりの全体像
- 401エラーの解消方法はまず再ログインとauth.json退避から試すこと
- 401エラーとは認証に失敗したときに返るエラーであること
- 401エラーの原因はログイン情報・APIキー・権限・環境変数に分かれること
- codex 401はChatGPTログインとAPIキー利用で対処が変わること
- VS CodeやCursorのcodex 401は古い認証ファイルが残っている可能性があること
- APIキー利用のcodex 401は権限と反映待ちを確認すること
401エラーの解消方法はまず再ログインとauth.json退避から試すこと
codex 401で最初に見るべきなのは、Codex側が今どの認証情報を使っているかです。OpenAI Developer Communityでは、VS Code / Cursorプラグインで stream error: exceeded retry limit, last status: 401 Unauthorized が出た事例に対して、.codex/auth.json を退避し、再ログインする方法が共有されています。特に「ChatGPTでログインする」方式を使っている場合、古い認証情報が残っているだけで401が出る可能性があります。
この方法は、難しい設定変更ではありません。いったんエディタやCodex関連アプリを終了し、認証ファイルをバックアップ名に変更してから、もう一度ログインし直す流れです。ただし、ファイルを消すのではなく退避にしておくのが安全です。万一別の問題だった場合でも、元の状態を確認しやすくなります。
🔧 基本の切り分け手順
| 順番 | 確認すること | 目的 |
|---|---|---|
| 1 | VS Code / Cursor / Codex Appを終了 | 認証ファイルの読み込み中を避ける |
| 2 | ~/.codex/auth.json を退避 |
古い認証情報を使わせない |
| 3 | Codexを再起動 | 新しい認証フローを出す |
| 4 | ChatGPTログインを選択 | APIキー混在を避ける |
| 5 | 再度コマンドを実行 | 401が消えたか確認 |
Windowsの場合は、環境によってパスが少し変わることがあります。一般的にはユーザーフォルダ配下の .codex を確認します。PowerShellで探すなら、$env:USERPROFILE\.codex のような場所を確認するのが自然です。WSLを使っている場合は、Windows側とWSL側で .codex が別になることもあるため、どちらのCodexを起動しているかも見ます。
💻 環境別のauth.json確認先
| 環境 | 見る場所の例 | 注意点 |
|---|---|---|
| macOS / Linux | ~/.codex/auth.json |
コミュニティ事例でよく出る形式 |
| Windows PowerShell | $env:USERPROFILE\.codex\auth.json |
Windows版Codex App利用時はこちらを確認 |
| WSL | /home/<user>/.codex/auth.json |
Windows側とは別管理の可能性 |
| VS Code Remote | リモート先のホーム配下 | ローカルとリモートで認証が分かれる場合あり |
OpenAI Developer Communityの事例では、auth.json を退避して再ログインしたことで解消したという反応が複数あります。もちろん、すべての401がこれで直るとは言い切れません。APIキー利用、外部プロバイダー、MCP認可の問題では別の確認が必要です。
参考: 「
mv ~/.codex/auth.json ~/.codex/auth.json.bak」という対処が共有されています。
https://community.openai.com/t/fix-for-vscode-cursor-plugin-stream-error-exceeded-retry-limit-last-status-401-unauthorized/1358372
重要なのは、最初からAPIキーを作り直したり、Codexを何度も再インストールしたりしないことです。401は「認証されていない」という意味なので、まずは現在保存されている認証状態をリセットして、正しい入口からログインし直すのが効率的です。
401エラーとは認証に失敗したときに返るエラーであること
401エラーは、一般的には「リクエストに必要な認証が通っていない」状態を示すHTTPステータスです。Codexで表示される401も、多くの場合は「Codexが送ったリクエストに対して、サーバー側が認証できないと判断した」という意味で考えると整理しやすくなります。
ただし、画面に出る文言は少しずつ違います。401 Unauthorized、Missing Authentication header、OpenAI rejected the request、exceeded retry limit などが組み合わさることがあります。見た目が違っても、まずは「認証情報がない、古い、違う、権限が足りない」のどれかを疑うのが基本です。
📌 401表示の読み方
| 表示例 | ざっくりした意味 | 最初に見る場所 |
|---|---|---|
401 Unauthorized |
認証に失敗 | ログイン状態・APIキー |
Missing Authentication header |
認証ヘッダーが送られていない可能性 | 環境変数・プロバイダー設定 |
exceeded retry limit |
再試行しても通らなかった | 根本原因は401側 |
OpenAI rejected the request |
OpenAI側で認証拒否 | APIキー・ログイン方式 |
Token exchange failed |
ログイン連携の交換処理に失敗 | 再ログイン・ブラウザ認証 |
Codexの401では、exceeded retry limit という言葉に引っ張られすぎないほうがよいです。これは「何度か再試行したが、最後まで401だった」という意味合いに近く、原因そのものは再試行回数ではなく認証側にあります。再試行を増やしても、認証情報が間違っていれば解決しないことが多いです。
🧭 エラー文と対応のマトリクス
| エラーの中心 | よくある状況 | 優先対応 |
|---|---|---|
| 認証ファイル | ChatGPTログイン後に突然401 | auth.json退避と再ログイン |
| APIキー | APIキーでログイン後に401 | キー権限・キー保存場所を確認 |
| 環境変数 | 外部プロバイダー利用時に401 | env名と値の有無を確認 |
| MCP | Figmaなどの連携で401 | プラグイン再認証・CLI経由設定 |
| プロバイダー | OpenRouter / Vercelなどで401 | baseURL / envKey / modelを確認 |
「401エラーとは何エラーですか？」という検索意図に対しては、ログインやAPIキーなどの認証が通っていないエラーと答えるのが自然です。ただし、Codexの場合は単純なパスワード間違いだけではなく、保存済みトークン、APIキー権限、プロバイダー設定、MCP認可など複数の層があります。
特に外部プロバイダーを使っている場合は、「Codexが悪い」のか「プロバイダー側のキーが悪い」のかを分ける必要があります。Vercel Communityの事例では、直接curlでAPIに投げて200が返るかどうかを確認する話が出ています。これは、Codexを通さずキー単体の有効性を見るための切り分けです。
参考: Vercel Communityでは、curlで直接APIを試し、Codex側とキー側を分けて確認する流れが示されています。
https://community.vercel.com/t/401-unauthorized-from-v0-dev-api-when-using-codex-cli/13431
つまり、codex 401は「Codexで起きている401」ではありますが、原因はCodex本体だけとは限りません。認証ファイル、APIキー、環境変数、プロバイダー、MCP認可のどこで止まっているかを順番に見ることが、遠回りに見えて最短です。
401エラーの原因はログイン情報・APIキー・権限・環境変数に分かれること
「401エラーの原因は？」と検索している人にまず伝えたいのは、原因を1つに決め打ちしないことです。Codex関連の事例を見ると、同じ401でも発生場所が違います。VS Code / Cursor拡張では保存済み認証ファイル、CLIではAPIキー、外部プロバイダーでは環境変数、Codex AppのMCPでは認可連携が問題になっている例があります。
原因を切り分けるときは、エラー文そのものよりも「何を使ってCodexを動かしているか」を先に見ます。ChatGPTログインなのか、OpenAI APIキーなのか、VercelやOpenRouterなどのプロバイダーなのか、Figma MCPのような連携なのかで、見る場所が変わります。
🧩 codex 401の主な原因分類
| 原因カテゴリ | 起きやすい場面 | 具体例 |
|---|---|---|
| 古いログイン情報 | ChatGPTログイン利用 | auth.jsonが古い |
| APIキー権限不足 | APIキー利用 | Read-onlyやRestrictedで通らない可能性 |
| 反映待ち | キー権限を変更直後 | 数分待つ必要がある場合 |
| 環境変数ミス | 外部プロバイダー | OPENROUTER_API_KEYなどが空 |
| provider設定ミス | Vercel / OpenRouter | baseURLやenvKeyの不一致 |
| MCP認可不良 | Figmaなど | プラグイン認証が通っていない |
APIキーの権限については、OpenAI Developer Communityの事例で「All permissionにしたら動いた」「変更後は5分ほど待つ必要がありそう」という投稿があります。これは個別事例であり、常に同じとは言い切れませんが、APIキー利用時の401ではかなり重要な確認ポイントです。
🔑 APIキー利用時の確認ポイント
| 確認項目 | 見る理由 | 補足 |
|---|---|---|
| キーが正しいか | 別キーや古いキーを使っていないか | コピー時の欠落にも注意 |
| 権限が足りるか | Restrictedだと通らない場合あり | 事例ではAll permissionで解消報告あり |
| 変更後に待ったか | 権限反映に時間がかかる可能性 | 数分待って再試行 |
| envに入っているか | CLIが参照できないと401 | 別シェルでは未設定のことあり |
| auth.jsonに保存されたか | Codexがそこから読む場合あり | envやconfigより優先関係に注意 |
また、環境変数の問題は見落としやすいです。たとえばPowerShell、cmd、WSL、VS Code内ターミナルでは、それぞれ環境変数の見え方が違うことがあります。「さっき設定したはず」でも、別のターミナルや別の環境でCodexを起動していると、値が渡っていない可能性があります。
外部プロバイダーでは、envKey の名前も重要です。OpenRouterならOpenRouter用、Vercel v0ならVercel用のキー名をCodex設定が参照している必要があります。キーが有効でも、Codexが別の環境変数を見ていれば401になります。
結論として、codex 401の原因は大きく分けて「保存済みログイン」「APIキー」「権限」「環境変数」「プロバイダー設定」「MCP認可」です。まず自分の利用パターンを分類し、その分類に合う場所から確認するほうが、無駄な再インストールを避けやすくなります。
codex 401はChatGPTログインとAPIキー利用で対処が変わること
Codexでは、ChatGPTログインを使うケースと、APIキーを使うケースがあります。この2つは似ているようで、401の直し方がかなり違います。ChatGPTログインではブラウザ認証や保存済みトークンが中心になり、APIキー利用ではキーの値、権限、保存場所、環境変数が中心になります。
OpenAI Developer CommunityのVS Code / Cursor事例では、「ChatGPTでログインし直す」対処が共有されています。一方、APIキー利用の人は同じ方法だけでは直らず、キー権限や保存先を確認する必要があるという流れになっています。つまり、自分がどちらの認証方式を選んだかが第一分岐です。
🚦 認証方式別の最初の一手
| 利用方式 | 最初に試すこと | 次に見ること |
|---|---|---|
| ChatGPTログイン | /logout や再ログイン |
auth.json退避 |
| OpenAI APIキー | キー権限確認 | auth.json / env / config |
| 外部APIキー | 直接curlで確認 | provider設定 |
| MCP連携 | プラグイン再認証 | CLI経由でMCP設定 |
| 不明 | Codexのログイン状態確認 | .codex配下の設定 |
ChatGPTログインの場合、エラーが突然出たならセッション切れやトークン不整合が考えられます。特に、モデル更新やアプリ更新のタイミングで認証状態が噛み合わなくなる可能性があります。公開事例でも、gpt-5-codexリリース後に401が出るようになり、認証ファイル退避で直ったという流れが見られます。
🧪 ChatGPTログイン側の切り分け
| 症状 | 可能性 | 対応 |
|---|---|---|
| 突然401になった | 保存済みトークンが古い | ログアウト・再ログイン |
| VS Codeだけ失敗 | 拡張が古い認証を参照 | エディタ終了後にauth退避 |
| ブラウザ認証後も失敗 | 認証交換の不整合 | 再起動・別ブラウザ確認 |
| AppとCLIで挙動が違う | 参照設定が別 | それぞれの.codexを見る |
APIキー利用では、話が変わります。キーそのものが無効、権限が足りない、権限変更がまだ反映されていない、Codexが別のキーを見ている、などが起きます。GitHub Issue #2896では、APIキーでログインしてコマンドを実行すると401が出る事例が報告されています。
参考: GitHubのopenai/codex Issue #2896では、APIキー利用時の401が報告されています。
https://github.com/openai/codex/issues/2896
ここで注意したいのは、APIキーを環境変数にもconfigにもauth.jsonにも入れてしまうと、どれが使われているか分かりにくくなることです。事例では「auth.jsonに入っていれば十分で、envやconfigに追加しなくてもよさそう」という投稿もありますが、これは環境やバージョンで変わる可能性があります。
そのため、codex 401では「ログインし直す」だけでなく、自分はChatGPTログインなのか、APIキーなのか、外部プロバイダーなのかを先に決めてから対処しましょう。認証方式を混ぜたまま試行錯誤すると、原因がかえって見えにくくなります。
VS CodeやCursorのcodex 401は古い認証ファイルが残っている可能性があること
VS CodeやCursorでCodexを使っている場合、CLI単体とは別に、拡張機能側が保存済みの認証情報を参照している可能性があります。そのため、ターミナルではログインできているように見えても、拡張側では401が出続けることがあります。
OpenAI Developer Communityの事例では、VS Code / Cursorを終了し、~/.codex/auth.json を auth.json.bak に変更してから再起動し、ChatGPTログインを選ぶ流れが紹介されています。この流れで直ったという返信も複数あります。つまり、VS Code / Cursor周りでは古い認証ファイルの残留が有力な原因の1つです。
🧰 VS Code / Cursor向けの確認表
| 確認項目 | 内容 | 補足 |
|---|---|---|
| エディタを閉じたか | 認証ファイルの再読み込みを確実にする | 起動中だと反映しない場合あり |
| auth.jsonを退避したか | 古いトークンを使わせない | 削除より退避が安全 |
| ChatGPTログインを選んだか | APIキー混在を避ける | 事例ではこちらが有効 |
| 拡張を再起動したか | 新しい認証を読ませる | VS Code本体ごと再起動 |
| CLIでも確認したか | 拡張固有か全体か切り分け | CLIで動けば拡張側の可能性 |
また、CursorやVS Codeでは、拡張機能の更新、Codex側の更新、モデル更新が重なると、以前の認証状態が合わなくなる可能性があります。もちろん、これは推測の域を出ませんが、公開事例ではgpt-5-codexリリース後に同様の401が増えたという文脈があります。
📎 やりがちな遠回り
| 遠回りな対応 | なぜ先にやらないほうがよいか | 先にやること |
|---|---|---|
| 拡張を何度も再インストール | 認証ファイルが残ると変わらない可能性 | auth.json退避 |
| APIキーを何本も作る | ChatGPTログインの問題なら無関係 | ログイン方式を確認 |
| PCを何度も再起動 | 認証情報が変わらなければ同じ | 保存ファイルを確認 |
| configを書き換える | 参照元がauthなら効かない可能性 | どこを読んでいるか確認 |
VS Code / Cursorで401が出る人は、「Codex CLIではどうか」も確認するとよいです。CLIでも401なら認証全体の問題、CLIでは動くが拡張だけ失敗するなら拡張側の認証参照やMCP連携の問題に寄せて考えられます。
短く言えば、VS Code / Cursorのcodex 401は、拡張の不具合と決める前に、古い認証情報を退避して再ログインするのが第一候補です。特にChatGPTログイン利用者は、この手順が最もシンプルな確認になります。
APIキー利用のcodex 401は権限と反映待ちを確認すること
APIキーでCodexを使っている場合、401の原因は「キーが間違っている」だけではありません。権限が足りない、キー変更直後で反映されていない、Codexが別のキーを参照している、キーを保存した場所が想定と違う、などが考えられます。
OpenAI Developer CommunityのAPIキー利用者の投稿では、Read-onlyやRestrictedではうまくいかず、All permissionにしたら動いたという趣旨の報告があります。また、権限変更後に数分待つ必要がありそうだという話もあります。これは個別事例ですが、APIキー利用時の401では優先度の高い確認です。
🔐 APIキー権限の確認表
| 状態 | 起きる可能性 | 対応 |
|---|---|---|
| Read-only | リクエストが許可されない可能性 | 必要権限を見直す |
| Restricted | 対象APIに権限がない可能性 | 利用範囲を確認 |
| All permission | 事例上は解消報告あり | セキュリティ方針と相談 |
| 変更直後 | 反映前の可能性 | 数分待って再試行 |
| 古いキー | 失効・削除済みの可能性 | 新しいキーと差し替え |
APIキーを使うときは、保存先も重要です。Codexが初回ログイン時にAPIキーを auth.json に保存する場合、環境変数やconfigに同じキーを重ねて入れる必要がないこともあります。逆に複数箇所に違うキーがあると、「どのキーで401が出ているのか」が分かりにくくなります。
🧭 キー保存場所ごとの注意点
| 保存場所 | メリット | 注意点 |
|---|---|---|
auth.json |
Codexが直接参照しやすい | 古いキーが残ると混乱 |
| 環境変数 | CLIや外部ツールで使いやすい | ターミナルごとに見え方が違う |
config.toml / config.yaml |
設定として管理しやすい | バージョンで形式が違う可能性 |
| シェル設定ファイル | 永続化しやすい | WSL / Windowsで別管理 |
| 拡張機能の入力欄 | GUIで簡単 | 実際の保存先が見えにくい |
APIキー利用者がやるべきことは、まずキーの有効性を単体で確認することです。OpenAIのAPIキーであればOpenAI側の確認、Vercel v0のキーであればVercel APIへ直接確認、OpenRouterであればOpenRouterのAPIへ直接確認する、という形です。Codexを挟まないテストで401なら、Codexではなくキー側の問題に寄ります。
GitHub Issue #1332やVercel Communityの事例では、Vercel v0のAPIキーを使ったときの401が話題になっています。そこでは、curlで直接APIを叩いて401か200かを見る流れが重要視されています。これは、Codex設定の問題とAPIキー自体の問題を分けるためです。
参考: Vercel v0 APIキーをCodex CLIで使う際の401事例。
https://github.com/openai/codex/issues/1332
APIキー利用のcodex 401では、「キーを入れ直したのに直らない」と感じることが多いです。しかし実際には、権限、反映待ち、保存場所、参照先のズレが絡みます。まずはキーを1つに絞り、どこに保存され、Codexが何を読んでいるかを見える状態にするのが近道です。
ポチップ
codex 401を潰すための実践チェックリスト
- Codex CLIの401は/logout後の再ログインで直る場合があること
- Codex AppやMCPの401はプラグイン認可を疑うこと
- OpenRouterやVercelの401は認証ヘッダーと環境変数を見ること
- 「codex 401」についてAI回答を見る前に公式コミュニティとIssueを確認すること
- 再インストールより先に設定ファイルと参照キーを整理すること
- それでも直らない場合は最小再現とログを揃えて問い合わせること
- 総括：codex 401のまとめ
Codex CLIの401は/logout後の再ログインで直る場合があること
Codex CLIで stream error: exceeded retry limit, last status: 401 Unauthorized が出る場合、まずはCLIのログイン状態を疑います。OpenAI Developer CommunityのCodex CLI関連スレッドでは、/logout してログインし直す、API利用なら環境変数を確認する、という方向のコメントがあります。
CLIでは、認証情報がターミナル環境、.codex 配下のファイル、設定ファイルのいずれかに依存します。そのため、GUIアプリよりも切り分けはしやすい一方で、複数環境を使っていると混乱しやすいです。Windows、WSL、VS Code内ターミナル、PowerShellで状態が違うこともあります。
🧪 CLIで最初に試す順番
| 順番 | 操作 | 目的 |
|---|---|---|
| 1 | Codexのログイン方式を確認 | ChatGPTかAPIキーかを分ける |
| 2 | /logout またはログアウト操作 |
古い認証を外す |
| 3 | 再ログイン | 新しい認証情報を取得 |
| 4 | まだ401ならauth.json退避 | 保存済み情報をリセット |
| 5 | APIキー利用ならenv確認 | キーが渡っているか確認 |
/logout で直るケースは、ログイン情報が期限切れ、破損、またはアカウント切り替えで不整合を起こしている場合に考えられます。ただし、APIキーや外部プロバイダーの問題では、ログアウトだけでは直らない可能性があります。
🧩 CLIの401切り分けマトリクス
| CLIでの状況 | 推測される方向 | 次の確認 |
|---|---|---|
| ChatGPTログイン後に401 | セッション不整合 | /logout → 再ログイン |
| APIキー入力後に401 | キー権限・キー保存 | 権限とauth.json確認 |
| 外部providerで401 | env / config | envKeyとbaseURL確認 |
| AppでもCLIでも401 | 共通認証の問題 | .codex全体を確認 |
| CLIだけ401 | CLI側設定の問題 | configと実行環境確認 |
OpenAI Developer CommunityのCLIスレッドでは、数時間使ったあとに401が出続けるようになったという投稿もあります。このような場合、サーバー側の一時的な問題の可能性もゼロではありませんが、まず自分の認証状態を更新するほうが現実的です。
参考: Codex CLIで401が出る事例と、ログアウト・再ログインの提案。
https://community.openai.com/t/codex-cli-toast-exceeded-retry-limit-401-unauthorized/1361830
CLIの良いところは、エラーの再現が取りやすいことです。どのコマンドで、どのモデルで、どのproviderで、どの環境変数を使ったかを記録すれば、問い合わせ時にも伝えやすくなります。逆に、毎回違う設定を試すと原因が追えなくなります。
Codex CLIの401では、ログアウト・再ログイン、auth.json退避、APIキー権限、環境変数の順で確認するのが実務的です。特に複数の認証方式を試したあとなら、一度設定を整理してから再テストするのが重要です。
Codex AppやMCPの401はプラグイン認可を疑うこと
Codex AppでFigmaなどのMCP連携を使っている場合、401はOpenAIアカウントのログインだけでなく、MCPサーバーや外部サービス側の認可で起きている可能性があります。Figma Forumでは、Codex App内のFigmaプラグインで401が出続けた事例があり、プラグインの削除・再追加、再認証、VPN確認などが話題になっています。
この種の401は、通常のCodex CLIの401と少し違います。Codex本体にはログインできていても、Figma MCPの認可だけが通っていなければ、MCP操作時に401になる可能性があります。つまり、「Codexにログインできているから認証問題ではない」とは言い切れません。
🔌 MCP連携で見る場所
| 確認対象 | 内容 | 補足 |
|---|---|---|
| Codex本体ログイン | OpenAIアカウント側 | ここが通っていてもMCPは別 |
| MCPプラグイン | Codex App内の連携 | 削除・再追加で改善する場合あり |
| 外部サービス認可 | Figmaなどの接続許可 | connected appsを確認 |
| ネットワーク | VPNや社内制限 | 別回線で変わるか確認 |
| CLI経由設定 | App側設定の代替 | 事例ではCLI経由で改善報告あり |
Figma Forumのやり取りでは、プラグインを何度も再インストールしても直らず、VPNでもなく、最終的にCodex CLIをインストールしてCLI経由でFigma MCPを入れたらCodex App側も動いた、という流れが紹介されています。これは個別事例ですが、App側のMCP設定がうまく作られていない場合の参考になります。
🧭 MCP 401の切り分け順
| 順番 | 試すこと | 判断できること |
|---|---|---|
| 1 | プラグイン削除・再追加 | 認可の作り直しで直るか |
| 2 | ブラウザで再認証 | 外部サービスの承認が通るか |
| 3 | VPNを切る / 別回線 | ネットワーク要因か |
| 4 | connected apps確認 | 認可済みとして見えているか |
| 5 | CLI経由でMCP設定 | App側設定不備の回避になるか |
MCPの401では、Codexのログイン情報だけを何度も消しても直らないことがあります。なぜなら、問題がOpenAIログインではなく、Figmaなど外部サービスとの接続許可にあるかもしれないからです。プラグインごとに認証の仕組みがあると考えると理解しやすいです。
参考: Figma Forumでは、Codex AppのFigmaプラグインで401が出る事例が共有されています。
https://forum.figma.com/report-a-problem-6/figma-plug-in-does-not-work-in-codex-app-53545
MCP関連で401が出るときは、「Codex本体」「MCP設定」「外部サービス認可」「ネットワーク」の4層に分けると整理できます。特にチーム内の複数人で同じ401が出る場合、個人のトークンだけでなく、プラグイン側やネットワーク側の問題も候補になります。
Codex AppやMCPの401は、再ログインだけで終わらせず、プラグイン認可を作り直すことが大切です。削除・再追加、外部サービス側のconnected apps確認、必要に応じたCLI経由の設定まで見ると、原因に近づきやすくなります。
OpenRouterやVercelの401は認証ヘッダーと環境変数を見ること
CodexでOpenRouter、Vercel v0、DeepSeek、Geminiなど外部プロバイダーを使う場合、401はOpenAI側ではなく外部プロバイダー側から返っていることがあります。この場合、Codexのログインを直しても改善しない可能性があります。
GitHub Issue #13888では、OpenRouterのResponses API向けURLで Missing Authentication header が出ている事例があります。この文言は、APIキーが送られていない、またはCodex設定が期待した環境変数を参照できていない可能性を考える材料になります。
🌐 外部プロバイダー利用時の見る場所
| 項目 | 確認内容 | 例 |
|---|---|---|
| baseURL | 正しいAPIエンドポイントか | https://openrouter.ai/api/v1 など |
| envKey | 正しい環境変数名か | OPENROUTER_API_KEY |
| 環境変数の値 | 空ではないか | 同じシェルで確認 |
| model名 | provider側で使えるか | 指定ミスに注意 |
| 認証ヘッダー | Bearerが付くか | 直接curlで確認 |
外部プロバイダーで大事なのは、Codexを通さず直接APIを叩くテストです。Vercel Communityでは、curlで直接Vercel v0 APIに投げ、200が返るか確認する流れが示されています。直接curlで401ならキーやプロバイダー側の問題、curlで200なのにCodexで401ならCodex設定や環境変数参照の問題に寄ります。
🧪 direct APIテストの考え方
| 結果 | 解釈 | 次に見る場所 |
|---|---|---|
| curlでも401 | キー側・権限側の問題が濃い | プロバイダー管理画面 |
| curlは200、Codexは401 | Codex設定側が怪しい | config / envKey |
| curlが環境により違う | 環境変数の引き継ぎ問題 | 実行シェル |
| Missing header | キーが送られていない可能性 | envの空値 |
| 別キーで変わる | キー個別の問題 | キー再発行や権限 |
Vercelの事例では、OPENAI_API_KEY と外部プロバイダー用キーが混在していることが原因に見える報告もあります。Codexが本来のproviderではなくOpenAI側のキーを使ってしまう、あるいはprovider切り替えが期待通りに効かない、といった問題です。
参考: OpenRouter向けURLで
Missing Authentication headerが出るGitHub Issue。
https://github.com/openai/codex/issues/13888
外部プロバイダーの401では、Codexの「provider」「model」「baseURL」「envKey」の組み合わせを1セットで確認します。どれか1つでもズレると、正しいキーを持っていても401になります。特にWindowsとWSLをまたぐ場合、環境変数を設定した場所とCodexを実行する場所が違うことがあるため注意が必要です。
つまり、OpenRouterやVercelのcodex 401は、OpenAIログイン問題ではなく、認証ヘッダーが正しく作られているかの問題として見るべき場面があります。直接APIテストでキー単体を確認し、その後Codex設定を確認する順番がわかりやすいです。
「codex 401」についてAI回答を見る前に公式コミュニティとIssueを確認すること
検索結果には「『codex 401』についてAI回答を見る」という意図も含まれています。AI回答は概要をつかむには便利ですが、401のような環境依存のエラーでは、実際のIssueやコミュニティ投稿のほうが具体的な手がかりになることがあります。
特にCodexは、CLI、App、拡張機能、MCP、外部providerなど利用形態が広いです。AI回答だけを見ると「再ログインしてください」で終わりがちですが、実際にはAPIキー権限、auth.json、envKey、MCP認可、provider設定など、別々の原因が混在しています。
📚 情報源ごとの使い方
| 情報源 | 向いていること | 注意点 |
|---|---|---|
| OpenAI Developer Community | 同様の症状と対処例 | 個別環境の報告も多い |
| GitHub Issues | バージョン・再現条件の確認 | Close済みでも参考になる |
| Vercel Community | 外部provider固有の確認 | OpenAI側とは別問題 |
| Figma Forum | MCP / プラグイン連携 | Codex本体以外の認可を見る |
| AI回答 | 全体像の把握 | 最新状況は必ず確認したい |
AI回答を使うなら、エラー文をそのまま入れるより、状況を分けて質問したほうが精度が上がります。たとえば「Codex CLIでChatGPTログイン後に401」「CodexでOpenRouter providerを使うとMissing Authentication header」「Figma MCP in Codex Appで401」のように、利用形態を入れると原因候補が絞られます。
🔎 検索・質問時に入れるべき情報
| 入れる情報 | なぜ必要か |
|---|---|
| Codex CLI / App / VS Code / Cursor | 対処が変わる |
| ChatGPTログイン / APIキー | 認証方式が違う |
| エラー全文 | Missing headerなどが手がかり |
| OS | Windows / WSL / macOSでパスが違う |
| provider | OpenAI / Vercel / OpenRouterで確認先が違う |
| model名 | provider側対応モデルか確認できる |
GitHub Issue #2896では、Codexのバージョン、モデル、OS、再現手順、実際のエラーが整理されています。この形式は、自分で問い合わせるときにも役立ちます。単に「401で動きません」より、再現条件があるほうが原因を見つけやすいです。
参考: Codexの401 Issueでは、バージョン・モデル・OS・再現手順が整理されています。
https://github.com/openai/codex/issues/2896
また、Redditの検索結果が出ることもありますが、今回確認できる範囲では本文が取得できず「Please wait for verification」と表示されるものがありました。このようなページは中身を確認できないため、根拠としては扱いにくいです。読める一次情報に近いページを優先したほうが安全です。
結論として、「codex 401」についてAI回答を見るのは入口としては有用です。ただし実際に直す段階では、公式コミュニティ、GitHub Issue、利用中providerのコミュニティ、MCP提供元のフォーラムを確認し、自分の環境に近い事例を探すほうが実用的です。
再インストールより先に設定ファイルと参照キーを整理すること
codex 401が続くと、Codex本体や拡張機能を再インストールしたくなります。しかし公開事例を見る限り、再インストールだけでは解消しないケースがあります。理由は、認証ファイルや設定ファイルが残っていれば、再インストール後も同じ古い情報を読み続ける可能性があるからです。
先にやるべきなのは、Codexが参照している設定ファイルとキーを整理することです。auth.json、config.toml、config.yaml、config.json、環境変数、拡張機能の設定などが候補になります。どれか1つに古いキーや別providerの設定が残っていると、401の原因になります。
🧹 再インストール前の整理リスト
| 対象 | 何を確認するか | メモ |
|---|---|---|
auth.json |
古いログインやAPIキーがないか | 退避して再ログイン |
| config系ファイル | provider / model / envKey | 形式は環境で異なる |
| 環境変数 | 不要なキーが残っていないか | WSLとWindowsで別 |
| 拡張機能設定 | APIキー入力欄やログイン状態 | VS Code / Cursor |
| MCP設定 | 外部サービス認可 | Figmaなど |
特に外部providerを試したあとにOpenAIへ戻す場合、設定が混ざることがあります。Vercel Communityの事例では、provider切り替えやconfigコマンドの挙動に関する問題も話題になっています。バージョンやNode環境によっては、設定コマンドが期待通り動かない可能性もあるため、設定ファイルの中身を直接確認する価値があります。
🧭 参照キーを整理する考え方
| 状況 | 起きやすい問題 | 整理方針 |
|---|---|---|
| OpenAI APIキーと外部キーが両方ある | 誤ったキーを使う | 使わないキーを一時的に外す |
| envとauth.jsonに別キー | どちらが使われるか不明 | 片方に寄せる |
| WindowsとWSLで設定が違う | 片方だけ直している | 実行環境側を確認 |
| providerを何度も変えた | baseURLやmodelが混在 | 現在使うproviderだけ残す |
| GUIとCLIを併用 | 保存先が複数 | CLIで再現確認する |
再インストールは最後の手段ではありませんが、最初の手段としては効率が悪いことが多いです。アプリを入れ直しても .codex 配下が残るなら、認証状態は変わらない可能性があります。逆に、設定ファイルを正しく整理すれば、再インストールなしで直ることがあります。
また、設定ファイルを触るときは、削除ではなくバックアップが安全です。auth.json.bak のように名前を変えて残せば、必要に応じて戻せます。特に仕事環境や複数providerを使っている場合、いきなり削除すると復旧が面倒になるかもしれません。
codex 401では、再インストールよりも先に「今Codexがどの認証情報を使っているか」を見える化することが大切です。使う認証方式を1つに絞り、不要な環境変数や古い設定を外してから試すと、原因が見えやすくなります。
それでも直らない場合は最小再現とログを揃えて問い合わせること
ここまで確認してもcodex 401が直らない場合は、闇雲に設定を変え続けるより、問い合わせやIssue投稿に使える材料を揃えたほうがよいです。GitHub Issuesの投稿例を見ると、バージョン、モデル、OS、再現手順、実際のエラー文があると状況が伝わりやすくなります。
最小再現とは、「問題が起きる最も短い手順」のことです。たとえば、codex --provider vercel --model v0-1.0-md で401になる、curlでは200になる、WindowsではだめだがWSLでは違う、というように条件を絞ります。これにより、Codex側の問題か、キー側の問題か、環境側の問題かが見えやすくなります。
📝 問い合わせ前に集める情報
| 項目 | 例 | 目的 |
|---|---|---|
| Codexの種類 | CLI / App / VS Code拡張 | 対象を明確にする |
| バージョン | About CodexやCLI表示 | 既知不具合と照合 |
| OS | Windows / WSL / macOS | パスやenv差を確認 |
| 認証方式 | ChatGPT / APIキー / provider | 原因候補を絞る |
| エラー全文 | 401本文・request id | 調査の手がかり |
| 再現手順 | 何を実行したか | 第三者が追える |
ログを出すときは、APIキーやトークンをそのまま貼らないように注意が必要です。キーの末尾数文字や、キーの種類だけなら文脈として役立つことがありますが、完全なキーを公開すると悪用リスクがあります。GitHub Issueでもキーの一部だけを伏せる形が見られます。
🔒 公開してよい情報・伏せる情報
| 種類 | 扱い |
|---|---|
| Codexバージョン | 公開してよい |
| OS情報 | 公開してよい範囲が多い |
| エラー文 | キーが含まれなければ公開可 |
| APIキー全文 | 公開しない |
| auth.json本文 | 原則公開しない |
| request id | サポート用途では役立つ場合あり |
問い合わせ先は、問題の所在に合わせて選びます。OpenAIログインやCodex CLI本体ならOpenAI CommunityやGitHub Issues、Vercel v0ならVercel Community、Figma MCPならFigma Forumやプラグイン提供元、OpenRouterならOpenRouter側の確認が候補になります。
また、既存Issueがある場合は、新規投稿より既存Issueの内容を確認したほうが早いことがあります。Closedになっていても、回避策や重複先へのリンクがある場合があります。GitHub Issue #13888のようにduplicateとして閉じられているものも、関連する本体Issueを追う入口になります。
それでも原因が特定できない場合は、「直接APIでは通るか」「Codexだけで落ちるか」「ChatGPTログインでも落ちるか」「別providerでも落ちるか」を整理して伝えましょう。ここまで分けると、サポート側も「認証ファイル」「provider設定」「キー権限」「ネットワーク」のどれを見るべきか判断しやすくなります。
総括：codex 401のまとめ
最後に記事のポイントをまとめます。
- codex 401は認証に失敗している状態を示すエラーである。
exceeded retry limitは再試行の結果であり、根本原因は401側にある。- ChatGPTログイン利用時は、まずログアウト・再ログインを試すべきである。
- VS CodeやCursorでは、古い
auth.jsonが残って401になる場合がある。 auth.jsonは削除より退避が安全である。- APIキー利用時は、キーの値だけでなく権限も確認する必要がある。
- APIキー権限を変更した直後は、反映まで数分待つ場合がある。
- OpenRouterやVercelなど外部providerでは、環境変数と認証ヘッダーを確認すべきである。
- curlなどで直接APIを試すと、キー側とCodex側を切り分けやすい。
- Codex AppやMCPの401は、OpenAIログインではなくプラグイン認可が原因の場合がある。
- 再インストールより先に、認証ファイル・config・環境変数を整理すべきである。
- Windows、WSL、VS Codeターミナルでは、同じ環境変数が見えているとは限らない。
- AI回答だけで判断せず、公式コミュニティやGitHub Issueの事例を確認すべきである。
- 直らない場合は、Codexの種類、バージョン、OS、認証方式、エラー全文、再現手順を揃えるべきである。
- codex 401は原因を分類して順番に潰せば、解決に近づきやすいエラーである。
- https://community.openai.com/t/fix-for-vscode-cursor-plugin-stream-error-exceeded-retry-limit-last-status-401-unauthorized/1358372
- https://www.reddit.com/r/codex/comments/1nnah5d/why_is_my_codex_showing_a_401_stream_error_and/
- https://community.openai.com/t/codex-cli-toast-exceeded-retry-limit-401-unauthorized/1361830
- https://github.com/openai/codex/issues/2896
- https://www.reddit.com/r/codex/comments/1q8de7e/unexpected_status_401_unauthorized/
- https://www.instagram.com/codex_401/
- https://github.com/openai/codex/issues/1332
- https://forum.figma.com/report-a-problem-6/figma-plug-in-does-not-work-in-codex-app-53545
- https://github.com/openai/codex/issues/13888
- https://community.vercel.com/t/401-unauthorized-from-v0-dev-api-when-using-codex-cli/13431
各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。
