# Codexの401「Incorrect API key」：URLとキーで原因を見分ける

> ChatGPTサインインのCodexで、エラーのURLがchatgpt.com/backend-apiなら自分のキーは無関係です。障害情報を見て、認証ファイルは消さずに待ちます。

- URL: https://blog.laozhang.ai/ja/posts/codex-401-incorrect-api-key
- Published: 2026-10-01
- Updated: 2026-10-01
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about)
- Category: AI
- Tags: Codex, 401 Unauthorized, Incorrect API key, ChatGPTサインイン, auth.json

---
`unexpected status 401 Unauthorized: Incorrect API key provided`は、本来はAPIキーでOpenAIのAPIを呼んだときに「そのキーは正しくない」と返すためのメッセージです。ChatGPTアカウントでサインインしている人はAPIキーを使っていないので、このメッセージが出ても自分のキーが間違っているわけではありません。その場合に疑う順番は、OpenAI側の障害、次にサインイン情報の更新失敗です。

どちらなのかは、エラー行に書かれている2つの文字列と、コマンド1つでほぼ決まります。

1. `url:`の後ろが`chatgpt.com/backend-api`か、`api.openai.com`か、自分で設定したアドレスか
2. `Incorrect API key provided:`の直後に出ているキーが、自分のキーか、見覚えのない文字列か、`dummy`か
3. `codex login status`の結果が`Logged in using ChatGPT`か、APIキーか

APIキーを作り直す、`~/.codex`を消す、CLIを古い版に戻す、といった操作は、この3点を見てからで間に合います。原因がOpenAI側にある間は、手元の認証情報を作り直しても401のままで、消したものは戻りません。

## 401を返したのはどこか：URL・キーの文字列・サインイン方式で決まる

エラー行の組み合わせごとに、401を返した場所と最初の一手は次のように分かれます。

| エラー中のURL | 表示されるキー | サインイン方式 | 401の出どころ | 最初にやること |
| --- | --- | --- | --- | --- |
| `chatgpt.com/backend-api/codex/responses` | `sk-svcac`で始まる、自分のものではないキー | ChatGPTアカウント | OpenAIのサーバー側 | ステータスページを確認して待つ |
| `api.openai.com/v1/responses` | `dummy` | ChatGPTアカウント | 手元のCodex。トークン更新に失敗している | サインインし直す |
| `api.openai.com` | 自分のキーの先頭と末尾 | APIキー | OpenAI Platform。キーが正しくない | キーを確認するか作り直す |
| `config.toml`に書いたアドレス | そのサービスで発行されたキー | カスタムプロバイダー | そのプロバイダー | `env_key`の環境変数とbase URLを確認する |

![エラー行のURL、表示されるキー、サインイン方式の4つの組み合わせから、401の出どころと最初にやることを示した対応図](https://blog.laozhang.ai/posts/ja/codex-401-incorrect-api-key/img/401-source-by-url-and-key.webp)

1行目は2026年9月の障害で多くの人が見た形、2行目はGitHubのissue [#37192](https://github.com/openai/codex/issues/37192)で報告されている形です。2行目についてOpenAIの確認や修正版の案内は出ていませんが、キーの欄が`dummy`でURLが`api.openai.com`という2点で1行目と区別できます。

同じ401でも、メッセージが`{"detail":"Unauthorized"}`だけの場合は別の症状です。[#41975](https://github.com/openai/codex/issues/41975)では、このメッセージと一緒に「refresh tokenが取り消されたのでログアウトしてサインインし直してください」という案内が出ています。こちらは案内どおり`codex logout`と`codex login`で対処します。

`exceeded retry limit`、429、`stream disconnected`が一緒に出ているときは、認証以外の層も関係します。その切り分けは[Codexの401・429・Stream Disconnected：失敗した層を見つける](https://blog.laozhang.ai/ja/posts/codex-exceeded-retry-limit-429)にまとめてあります。

## 2026年9月26日朝の障害：07:33〜08:47、ChatGPTサインインだけ401に

日本時間の2026年9月26日朝、ChatGPTアカウントでサインインしているCodexだけが一斉にこのエラーで止まりました。OpenAIの[障害報告書](https://status.openai.com/incidents/01M3DCNWMW57HYK8FJ5FBFPA39/write-up)によると、太平洋夏時間の2026年9月25日午後3時33分頃から午後4時47分頃まで、ChatGPTでサインインしてCodexを使うユーザーに認証エラー（401）とゲートウェイエラー（502）が発生しました。自分のAPIキーでCodexを使っていた人には影響がありませんでした。

太平洋夏時間はUTC−7、日本時間はUTC+9なので、16時間足すと日本時間になります。

| 日本時間（9月26日） | 出来事 | 出典 |
| --- | --- | --- |
| 07:33頃 | ChatGPTサインインのリクエストが失敗し始める | 障害報告書 |
| 07:58 | ステータスページに「Issues with Codex」が掲載される | ステータスページ |
| 08:19 | 「Login via API key will unblock access at this time.」と案内 | ステータスページ |
| 08:34 | 根本原因を特定 | ステータスページ |
| 08:39 | 止められていた認証情報が再び有効になる | 障害報告書 |
| 08:47頃 | サービスがおおむね復旧 | 障害報告書 |
| 08:54 | Resolved | ステータスページ |

影響が出ていた時間は報告書の基準で約74分、[ステータスページ](https://status.openai.com/incidents/01M3DCNWMW57HYK8FJ5FBFPA39)に障害として掲載されていた時間は56分です。最初の25分ほどは、エラーは出ているのにステータスページには何も載っていない状態でした。ステータスページが正常でも、エラーが出始めて間もないうちは障害の可能性が残ります。

![2026年9月26日朝の障害を日本時間で並べた時系列と、影響時間約74分、ステータスページ掲載56分、未掲載だった最初の約25分の比較](https://blog.laozhang.ai/posts/ja/codex-401-incorrect-api-key/img/sept-26-outage-timeline-jst.webp)

原因はユーザー側にはありませんでした。報告書によれば、認証情報の漏えいを検知して無効化する社内の仕組みが、Codexを支える内部サービス間の通信に使う認証情報を「漏えいの疑いあり」と誤って判定し、既存の保護を迂回する手動操作でその認証情報が失効しました。検知のきっかけになった通信は正当なもので、内部の認証情報は実際には漏えいしていなかった、とOpenAIは書いています。

このとき表示されたエラーは次の形でした（[#48237](https://github.com/openai/codex/issues/48237)、[#48241](https://github.com/openai/codex/issues/48241)）。

```text
unexpected status 401 Unauthorized: Incorrect API key provided: sk-svcac***...***fvMA.
You can find your API key at https://platform.openai.com/account/api-keys.,
url: https://chatgpt.com/backend-api/codex/responses, cf-ray: ..., request id: ...
```

別々のユーザーが貼ったエラーで、伏せ字になったキーの先頭と末尾が同じ`sk-svcac`と`fvMA`でした。全員が同じキーを見ている以上、これは利用者それぞれのキーではないと考えるのが自然です。内部サービスの認証情報が失効したという報告書の説明とも合いますが、表示されたキーがその認証情報だとOpenAIが明言したわけではなく、`sk-svcac`という接頭辞の意味も公開されていません。

報告者の環境も共通しています。`codex login status`は`Logged in using ChatGPT`、環境変数`OPENAI_API_KEY`、`CODEX_API_KEY`、`OPENAI_BASE_URL`は未設定、CLIは0.157.0でも0.148.0でも再現、OSはmacOS、Windows、Linuxのすべてで報告がありました。手元の設定に共通点がなく、同じ時刻に同じキーで失敗しているなら、直す場所は手元にありません。

## 障害中に消してはいけないもの：auth.jsonを消しても401は直らない

サーバー側の障害で出ている401は、手元の操作では直りません。直ったように見える報告はありますが、どれもサーバーの復旧と時刻が重なっています。

- **CLIを0.148.0に下げたら直った**という報告（[#48302](https://github.com/openai/codex/issues/48302)）は、日本時間08:56の投稿で、Resolvedの2分後です。一方で、0.148.0でも同じ失敗が出たという報告が#48241にあります。
- **サインインし直さず、再起動しただけで直った**という報告（[#48570](https://github.com/openai/codex/issues/48570)）は、失敗していた時間帯が障害と復旧の時間帯に重なっています。OpenAIの担当者は日本時間08:51に「Recovery is rolling out through clusters」と書いており、復旧は全員同時ではなく順番に届きました。
- **認証ファイルを作り直したら直った**という報告も、同じ理由で、作り直しが効いたのか待っている間に復旧したのか区別できません。

効果が確かめられていないうえに、失うものがあります。

| 操作 | 障害中に行うと起きること |
| --- | --- |
| `codex logout`、`~/.codex/auth.json`の削除 | CLIとIDE拡張機能はサインイン情報を共有しているので、両方でサインインし直しになる。障害中はサインインし直しても401のまま |
| `state_5.sqlite`の削除 | 手元に保存されたタスクやセッションの状態が消えるおそれがある。OpenAIの認証ドキュメントにこのファイルの記載はなく、復旧手順としても挙げられていない |
| APIキーの再発行 | ChatGPTサインインではAPIキーを使っていないので関係がない。古いキーを削除すれば、そのキーを使っているほかのツールが止まる |
| CLIのダウングレード | 古い版でも同じ401が再現している |

ステータスページにCodexの障害が出ている間は、何も消さずに待つのが最も損の少ない選択です。OpenAIの担当者も障害中のissueで、追加の報告や`/feedback`の送信は不要だと伝えています。

## 待てないときはAPIキーでサインインできる：ただし従量課金になる

障害中でも作業を止められない場合は、APIキーでのサインインに切り替えると使えます。9月の障害では、ステータスページ自身が日本時間08:19にこの方法を案内しました。OpenAI Platformで発行したキーを環境変数に入れておき、次のコマンドで切り替えます（[Codexの認証ドキュメント](https://learn.chatgpt.com/docs/auth)）。

```bash
printenv OPENAI_API_KEY | codex login --with-api-key
```

切り替える前に知っておくことが3つあります。

- 利用分はChatGPTプランに含まれる枠からではなく、OpenAI PlatformのAPI料金として従量課金されます。金額はPlatformの料金ページの当日の表示が基準です。
- ChatGPTのワークスペースやクラウド側のサービスに依存する機能は、制限されるか使えません。Codex cloudはChatGPTサインインでしか使えません。
- サインイン情報はCLIとIDE拡張機能で共有されるので、切り替えは両方に効きます。

復旧したら`codex logout`のあと`codex login`でChatGPTサインインに戻します。戻し忘れると、その後の利用がすべてAPI料金になります。2つの方式で何が含まれ、どこに課金されるかは[Codex APIキーとChatGPTサブスクの違い: 先に選ぶべき経路](https://blog.laozhang.ai/ja/posts/codex-api-key-vs-subscription)で整理しています。

## 障害が終わっても401が出るとき：サインインし直すのはこの場合

ステータスページが正常なのに401が続くなら、ここで初めて手元を調べます。確認は次の順で進めます。

1. `codex login status`を実行します。ChatGPTでサインインしているつもりがAPIキーになっていた、という場合はここで分かります。
2. 環境変数を確認します。`OPENAI_API_KEY`、`CODEX_API_KEY`、`OPENAI_BASE_URL`に、以前の作業で設定した値が残っていないかを見ます。
3. エラー行のキーとURLを読み直します。キーが`dummy`、URLが`api.openai.com`なら、トークンの更新に失敗している形です。#37192では、ChatGPTサインインのままネットワークを切り替えた後にこの状態になったと報告されています。
4. サインインし直します。`codex logout`で保存済みの認証情報を消し、`codex login`で入り直します。認証情報は`auth.json`ではなくOSの資格情報ストアに保存されている場合もあるので、ファイルを手で消すよりこの2つのコマンドを使います。ChatGPTサインインのトークンは使用中に自動で更新される仕組みなので、通常はこの操作が必要になることはありません。

サインインし直しても同じ401で、URLが`chatgpt.com/backend-api`、キーが見覚えのない文字列のままなら、手元の認証情報が原因である可能性は低くなります。Windowsでは1件、別の原因が報告されています。[#48316](https://github.com/openai/codex/issues/48316)では、Codexデスクトップアプリの更新後に`codex.exe`の置き場所が変わり、Malwarebytesがそれを新しいプログラムとして外向きのHTTPS通信を遮断していました。ログには`Workspace routing is unavailable`と`Desktop network policy does not allow this destination`が残り、画面には同じ401が表示されたそうです。一人のユーザーの報告でOpenAIの確認はありませんが、アプリの更新直後から出ている場合は、セキュリティソフトやファイアウォールがCodexの通信を止めていないかを見る価値があります。

`codex login`そのものが403で止まる場合は症状が別なので、[Codexのトークン交換が403で失敗：ログイン・プロキシ・地域・認証キャッシュを切り分ける](https://blog.laozhang.ai/ja/posts/codex-token-exchange-failed-403)の手順に進んでください。

## APIキーでサインインしている場合：メッセージどおりキーを直す

APIキーでサインインしていて、エラーに出ているのが自分のキーの先頭と末尾なら、メッセージは文字どおりの意味です。OpenAIの[エラーコード一覧](https://developers.openai.com/api/docs/guides/error-codes#api-errors)は、`401 - Incorrect API key provided`の原因を「リクエストに使われたAPIキーが正しくない」とし、対処として、キーが正しいか確認する、ブラウザのキャッシュを消す、新しいキーを発行する、の3つを挙げています。

Codexの場合に見る場所は、環境変数に入っているキーと、`codex login --with-api-key`で保存したキーの2か所です。表示されたキーの先頭と末尾が、Platformの画面で有効になっているキーと一致するかを比べます。一致しなければ、古いキーや別のキーが残っています。新しいキーを発行したら、同じコマンドでサインインし直します。

同じ一覧には、401を返すメッセージがほかに3つ載っています。認証が無効（Invalid Authentication）、アカウントがどの組織にも属していない、許可されていないIPアドレスからのリクエスト、の3つです。メッセージが`Incorrect API key provided`でなければ、キーを作り直しても解決しません。

## カスタムプロバイダー経由の401：そのプロバイダーのキーとbase URLを見る

`config.toml`で自分のモデルプロバイダーを定義している場合、401を返しているのはそのプロバイダーで、9月の障害とは関係がありません。エラー行のURLが自分で設定したアドレスになっていることで見分けられます。

認証ドキュメントによると、カスタムプロバイダーの認証は3通りです。

- `requires_openai_auth = true`：OpenAIのサインイン情報を使う。このとき`env_key`は無視される
- `env_key`に環境変数名を書く：その環境変数に入っているプロバイダーのキーを使う
- どちらも書かない：認証なしとして扱われる

この3通りから、確認する点は3つに絞れます。`env_key`で指定した名前の環境変数に、そのプロバイダーのキーが入っているか。base URLがそのキーを発行したサービスを指しているか。`requires_openai_auth = true`のまま、OpenAI以外のサービスに接続していないか。設定の書き方は[Codex カスタムプロバイダー設定：APIキーとBase URLの選び方](https://blog.laozhang.ai/ja/posts/codex-config-toml)にあります。

## 切り分けをやめる目安と、サポートに渡す情報

ステータスページが正常で、`codex login status`が意図どおりの方式を示し、`codex logout`と`codex login`をやり直しても同じ401が出るなら、手元でできることは終わっています。これ以上ファイルを消したり版を入れ替えたりせず、問い合わせに切り替えます。

OpenAIのエラーコード一覧は、エラーが続く場合にサポートへ伝える情報として次を挙げています。

- 使っていたモデル
- エラーメッセージとコード
- リクエストの内容とヘッダー
- リクエストの時刻とタイムゾーン

Codexのエラー行には`request id`と`cf-ray`が含まれているので、行全体をそのまま写して渡します。そこに、`codex login status`の出力、Codexのバージョン、OS、CLI・デスクトップアプリ・IDE拡張機能のどれで起きたかを添えると、やり取りが減ります。`codex login`を実行したときにログ用のディレクトリへ書き出される`codex-login.log`も手がかりになります。

渡してはいけないのは`auth.json`です。アクセストークンが平文で入っているので、認証ドキュメントはパスワードと同じように扱い、チケットやチャットに貼らず、リポジトリにもコミットしないよう求めています。

GitHubにissueを立てる前には、ステータスページを見てください。障害として掲載されている間は、同じ報告を増やしても復旧は早まりません。

## 障害で止まった分の利用上限は戻るのか

9月の障害については、リセットするという担当者の発言はありますが、OpenAIの公式な告知には書かれていません。OpenAI Developer Communityの[スレッド](https://community.openai.com/t/codex-is-down-confirmed-by-openai/1400811)に引用されたXの投稿で、OpenAIでCodexを担当するTibo氏が「CodexとChatGPT Workのすべての有料ユーザーの利用上限をリセットする」と述べています。ステータスページと障害報告書には、利用上限についての記載がありません。自分のアカウントに反映されたかどうかは、実際の残量を見て確かめるしかありません。