直接回答
401 は応答したサービスでの認証失敗です。最初に、どのホストへ接続し、クライアントがどの認証情報を読み込んだかを確認します。
このガイドで解決できること
無効・失効・古い・誤送信された API 認証情報による HTTP 401 を修正する。
症状と影響範囲を確認する
DNS と TLS は成功する一方、すべての認証リクエストが 401 を返し、invalid_api_key や unauthorized と表示されます。
同じキーが curl や一つの端末では動作しても、IDE、daemon、CI、長時間動作するプロセスでは失敗します。
- 設定を変更する前に、ステータスまたは例外、レスポンス本文、request ID、UTC 時刻、クライアント版、最終ホストを保存します。
- 最小リクエストと失敗するワークフローを比較し、全体障害、モデル固有、機能固有のどれかを切り分けます。
- 認証情報、完全なプロンプト、顧客データ、非公開ファイルをスクリーンショットやサポート資料に含めません。
主な原因と責任境界
エラーは一つのレイヤーから得た証拠であり、下流全体の故障を証明するものではありません。まず次の可能性を順に検証します。
- キーが失効・取消済み、空白付き、または別サービス用。
- クライアントが古い環境変数、ログイン保存先、profile、プロセス環境を読み続けている。
- Bearer と x-api-key の認証方式を別プロトコル間で混同している。
- Base URL がキー発行元とは異なるゲートウェイを指している。
レイヤー別に最小診断を行う
可変要素が最も少ないリクエストから開始します。アカウント、API ホスト、対象モデルは維持し、任意機能だけを外します。
一度に一項目だけ変更し、元のステータス、ヘッダー、本文、所要時間を残します。これによりクライアントのシリアライズとゲートウェイ・上流の挙動を分離できます。
- 01境界を確定認証情報を見る前に最終ホストとプロトコルを確認します。
- 02基準を作成値は表示せず、想定する変数またはログイン状態の有無だけを確認します。
- 03一項目を比較対象エンドポイントの正式な認証ヘッダーを照合します。
- 04決定的な証拠を記録最小認証リクエストを実行し、対象クライアントを完全再起動して再確認します。
test -n "$API_KEY" && echo 'API_KEY is set' || echo 'API_KEY is missing'
codex login status 2>/dev/null || true
codenodex keys 2>/dev/null || true
# Claude Code 会话中另行运行 /status,切勿打印 token。確認した根本原因に修正を適用する
証拠で確定したレイヤーだけを最小限変更します。決定的な設定エラーを広範な再試行や検証無効化で隠さないでください。
- 01障害レイヤーを修正正しいサービス向けの認証情報を選択し、露出した値は取り消します。
- 02必要な動作を復元意図した secret 保存先または環境スコープを更新してクライアントを再起動します。
- 03一時回避策を除去エンドポイント、プロトコル、認証ヘッダーを一致させます。
一度の成功ではなく修正結果を検証する
最小確認が成功したら元の経路を再実行し、通常のストリーミング、同時実行数、タイムアウト条件でも安定することを確認します。
- 対象ホストへの最小リクエストが成功する。
- 旧キーまたは取消済みキーでは認証できない。
- 再起動したクライアントが新しい安全な保存先を読む。
- 履歴、ログ、画像、問い合わせに秘密値が残らない。
セキュリティ境界とエスカレーション資料
認証、通信、権限、検証を弱めず、かつ機密情報を公開しない範囲で、再現とエスカレーションに必要な証拠を収集します。
- 実キーをチャット、issue、画像、履歴に残るコマンド引数へ貼らない。
- 診断中に表示または共有したキーはローテーションする。
- 利用可能な最小 project・権限スコープを使う。
- サービスが許可する場合のみ fingerprint や末尾数文字で照合する。
公式情報と検証範囲
本ガイドはプロトコル仕様とクライアント公式文書を根拠にしています。エラー文、再試行ヘッダー、設定項目はサービスやバージョンで変わるため、参照元を確認し、ログとリクエスト例を秘匿してから共有してください。
技術検証方法を見る