Codex CLI の 401 は、リクエストを処理しているサーバーによって認証が拒否されたことを意味します。 手早く有効な確認を行うには、送信先ホスト、選択したプロバイダー、認証情報の取得元を組み合わせて確認します。環境変数が空である可能性はありますが、すべての 401 の原因がそれとは限りません。自分の設定に該当する分岐に従ってください。
まず、どの接続が失敗したかを特定する
| 失敗箇所 | 考えられる範囲 | 最初に確認すること |
|---|---|---|
| ChatGPT のサインインまたはトークン更新 | 保存されたアカウントセッション | アクティブなログインと対象のワークスペース |
| OpenAI API へのリクエスト | プラットフォームの認証情報とプロジェクト | キーの有効性とプロジェクトへのアクセス |
| カスタムゲートウェイへのリクエスト | そのプロバイダーの設定 | ホスト、プロバイダー ID、指定された環境変数 |
| MCP または外部ツールだけが失敗する | そのツール独自のログイン | ツール名とその認証 |
ステータス、エラーテキスト、タイムスタンプ、リクエスト ID(存在する場合)を保存してください。詳細を共有する前に、Authorization ヘッダー、キー、トークンを削除してください。サポートチケットに auth.json を貼り付けないでください。認証情報が含まれている可能性があります。1 つの統合で発生したエラーだけでは、モデル接続が壊れているとは判断できません。
1. CLI とログイン方法を確認する
codex --version
codex login status
# POSIX shell: report presence only, without printing the secret
if [ -n "${KUNAVO_API_KEY:-}" ]; then
printf 'KUNAVO_API_KEY is set\n'
else
printf 'KUNAVO_API_KEY is missing or empty\n'
fiCodex を起動するのと同じターミナルで確認コマンドを実行します。プロバイダーが別の env_keyを使用している場合は、存在確認で変数名を置き換えてください。「Set」は値が存在することだけを確認し、その値が最新であることや送信先に受け入れられることまでは証明できません。
更新が停止した個人用 ChatGPT ログインでは、 codex logout を実行してから codex login を実行し、対象アカウントでブラウザフローを完了してください。これにより保存済みのログイン状態が変更されます。すべてのカスタムプロバイダーエラーで必須の手順ではありません。管理された自動化環境では、管理者が指定した認証方法に従ってください。公式の認証ガイドを参照してください。
2. API キーを発行元と送信先に対応付ける
OpenAI Platform のキーは OpenAI API のルートで使用します。Kunavo のキーは Kunavo のルートで使用します。ChatGPT のブラウザログインに成功してもゲートウェイキーの有効性は確認できず、ゲートウェイの残高は OpenAI Platform の残高ではありません。何かを置き換える前に、エラーに表示された実際のホストを確認してください。
発行元のダッシュボードで、キーがまだ存在し、有効であることを確認します。関連付けられたプロジェクトとアクセス制限も確認してください。OpenAI API エラーリファレンスでは、認証エラーとして無効な認証情報、組織メンバーシップ、IP 許可リストの失敗が説明されています。付随するメッセージに基づいて修正方法を選択してください。キーを繰り返し作成しても、アカウントやネットワークポリシーは修復されません。
3. Codex が使用するプロバイダー設定を確認する
# Compare these non-secret fields with your intended provider.
model = "gpt-5-6-sol"
model_provider = "kunavo"
[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"
wire_api = "responses"選択した model_provider はプロバイダーブロックと一致している必要があります。env_key フィールドは変数名を指定するものであり、シークレット自体は含みません。アクティブな設定と、プロファイルまたはコマンドラインによる上書きを確認し、修正後に Codex を再起動してください。動作している設定に無関係なプロバイダーブロックをコピーして上書きしないでください。
OpenAI の 設定リファレンスでは Responses プロトコルが説明されています。 /v1 で終わるベース URL は、完全な /v1/responses リクエスト URL とは異なります。認証に成功した後でも、パスが間違っている場合は通常、エンドポイントの診断が必要です。requires_openai_auth も確認してください。有効な場合、認証ガイドの説明どおり、OpenAI 認証が env_key より優先されます。
4. 1 つだけ変更して、小さなタスクを 1 つ再試行する
- エラーの詳細を保持し、選択されたルートを特定します。
- 証拠が示しているログイン、認証情報、またはプロバイダーフィールドを修正します。
- 影響を受けた CLI またはエディタープロセスを再起動し、新しい設定を読み込ませます。
- 長時間のコーディングタスクを再開する前に、小さなリクエストを実行します。
- 失敗が続く場合は、認証情報ではなく、秘匿化したエラーとリクエスト ID をプロバイダーに送信してください。
後から発生した 429、残高警告、モデル欠落エラーは、新しい診断分岐です。認証の修正は維持し、すべての設定を元に戻すのではなく、次の問題に対処してください。Codex の制限ガイドでは、これらのケースが区別されています。Kunavo の設定では、完全な Codex 統合ガイドを使用し、キーはダッシュボードで管理してください。
よくある質問
Codex CLI の 401 は何を意味しますか?
リクエストを受信したサーバーが認証を拒否しました。原因としては、古くなったアカウントセッション、無効または失効したキー、誤ったプロバイダーに送信された認証情報、アカウントの制限が考えられます。認証情報を変更する前に、送信先と現在使用されている認証経路を確認してください。
codex login status でカスタムプロバイダーのキーを確認できますか?
CLIのログイン状態は報告されますが、環境変数を利用するカスタムプロバイダーがそのキーを受け入れることを証明するものではありません。その経路では、選択されているプロバイダー、起動プロセス内のenv_key変数、プロバイダー側のアカウント管理設定を確認してください。
あるターミナルではキーが使えるのに、IDEでは失敗するのはなぜですか?
プロセスごとに環境変数、プロファイル、設定が異なる可能性があります。変数を設定する前に起動したエディターは、その変数を継承していない場合があります。選択されているプロバイダーと起動環境を比較し、該当する設定を修正してから、影響を受けているプロセスを再起動してください。
認証の問題を解決するために Codex の設定を削除すべきですか?
まず、誤っているログイン設定またはプロバイダー設定を特定して対処してください。設定全体を削除すると、拒否された認証情報の問題に対処できないまま、無関係な設定まで失われる可能性があります。設定を保持し、対象を絞った修正を一度に一つずつ行ってください。
公式ドキュメントとローカル CLI ヘルプを 2026 年 9 月 17 日に確認済みです。これらの確認手順に認証情報を共有する必要はありません。