Codexのトークン交換が403で失敗する原因と対処：ログインの段階から切り分ける

Token exchange failed: token endpoint returned status 403 Forbidden が出たら、まずエラーの末尾と、Codexを動かしている場所を確認してください。ブラウザでのサインインが終わっていても、Codex側のトークン交換が成功したとは限りません。ブラウザから結果が戻らないならコールバックを、交換時に403が返るなら応答本文と通信経路を調べます。本文に地域・アカウント・ワークスペースの制限が明記されている場合は、ローカル設定を変え続けず、公式の利用条件や管理者に確認します。

手元で復旧を試す順序は、失敗した段階を特定する → その段階に関係する設定だけを直す → 元の環境でログインと小さな作業を確認する、です。最初から認証ファイルを消す必要はありません。

HTTPの403は「リクエストを理解したが、処理を拒否した」という意味です。RFC 9110の定義は、認証情報以外の理由でも拒否されうること、同じ認証情報で自動的に再送すべきではないことを説明しています。403という番号だけでは、OpenAIの認証サービス、途中のプロキシ、別のサービスのどこが拒否したかも決まりません。

エラーの末尾を残し、失敗した段階を見分ける

同じ「ログインできない」でも、対処する場所が違います。

コールバックを受け取れない状態と、トークン交換で明示的に拒否された状態を混ぜないでください。また、証明書の検証エラーはHTTP 403そのものではありません。TLSを直した後で403が残った場合は、別の拒否理由を調べる段階に進んだことになります。

ブラウザで本人確認を終える、Codexに認証結果が戻る、コードをトークンに交換する、認証情報を保存する、その認証で作業する、という順番で考えると判断しやすくなります。公式の認証ガイドでも、ブラウザからCodexへ認証情報を戻す流れと、保存・ログ・ヘッドレス環境の対処は別々に説明されています。

同じ実行ホストで記録する情報

問題の起きたターミナルで、次を確認します。Windowsホストで得た結果を、WSL内の状態として扱わないでください。

codex --version
codex login status

バージョン、認証方式、OS、CLI・アプリ・IDE拡張のどれで起きたか、WSL・コンテナ・SSH先かを記録します。アプリやIDEで起きた問題なら、そのクライアントのアカウント表示と実行環境も確認します。別のターミナルのCLIが正常でも、そのアプリの状態はまだ分かりません。

codex login statusの終了コードが0になるのは、CLIリファレンスによると認証情報が存在するときです。サーバーがその認証を受け入れたことや、作業が完了できることまでは証明しません。

エラーは最後の403だけでなく、直前の操作、短いエラーコード、秘密を除いた応答本文、時刻とタイムゾーン、request IDを一組で残します。unsupported_country_region_territoryのような末尾があれば、消さずに記録してください。完全なコールバックURL、authorization code、device code、access/refresh token、Cookie、API key、認証情報付きのプロキシURLは共有しません。

トークン交換の403では、応答本文から次の対処を選ぶ

明示的な交換403がある場合は、コールバック用のポートを変更するより先に、拒否理由を読みます。

HTMLに企業名があれば有用な手がかりですが、HTMLやJSONという形式だけで拒否元を断定はできません。途中のサービスが応答を変える場合もあるため、エラー本文にある送信先のホスト名とログの発生時刻を合わせて確認します。

OpenAI Statusも、障害の掲載内容と確認時刻を記録する入口になります。関連障害が掲載されている間は、その案内に従ってください。正常表示だけを根拠に個別のアカウントや通信経路が正常だとは判断できません。発生時点の障害状況と利用資格は、公式情報と対象アカウントで確認してください。

地域を示すエラーが出たとき

地域の拒否が明記されている場合、認証情報の削除やデバイスコードへの変更を繰り返すのをやめます。ChatGPTサインインならChatGPTの対応国・地域、APIキー利用ならOpenAI APIの対応国・地域を、その時点の公式情報として確認してください。日本語で利用していること自体は、接続元地域やアカウントの利用資格を示しません。

利用条件を満たしているのに拒否される場合は、時刻、実行ホストの構成、認証方式、地域を示すエラーコード、request IDをOpenAI Help Centerのサポートへ伝えます。会社の出口回線が関係する疑いがあれば、ネットワーク担当者にも経路を確認してもらいます。地域制限を回避するためのVPN変更や、他人のアカウントへの切り替えは復旧確認になりません。

プロキシと企業CAは、Codex側の環境で確認する

ブラウザがWebサイトを開けることと、WSL・コンテナ・SSH先のCodexが認証エンドポイントへ通信できることは別です。Codexを起動したプロセスにどの設定が届いているかを確認します。

環境変数の有無だけを確認したい場合、Python 3があるターミナルでは次の補助コマンドが使えます。プロキシのURLやパスワード、キーの値は出力しません。

python3 - <<'PY'
import os

names = (
    "HTTP_PROXY", "HTTPS_PROXY", "ALL_PROXY", "NO_PROXY",
    "http_proxy", "https_proxy", "all_proxy", "no_proxy",
    "CODEX_CA_CERTIFICATE", "SSL_CERT_FILE", "CODEX_HOME",
)
for name in names:
    state = "set" if os.environ.get(name) else "unset-or-empty"
    print(f"{name}: {state}")
PY

これは設定値の正しさや通信の成功を検査するものではありません。OSのシステムプロキシも表示しません。公式変更履歴には、ログインと起動時のリクエストにシステムプロキシのフォールバックを追加した記録があります。そのため「環境変数が空なら必ず直接接続」「Codexはシステムプロキシを一切使わない」とは言えません。利用中の版とOS、起動方法をそろえて管理者に確認します。

ローカルのコールバックと外向きの認証通信にも、別の経路があります。社内ルールに従い、ループバックの扱いと認証先への外向き通信を個別に確認してください。OpenAI関連ドメインを一括でNO_PROXYに加えると、必須の企業プロキシを外してしまう場合があります。

証明書チェーンのエラーがあり、企業TLS検査に必要なCAが正しく配布されている場合は、公式ガイドの次の設定を使えます。パスは管理者から受け取ったPEMファイルに置き換えます。

export CODEX_CA_CERTIFICATE="/path/to/corporate-root-ca.pem"
codex login

カスタムCAの公式説明では、CODEX_CA_CERTIFICATEが未設定ならSSL_CERT_FILEを使い、ログイン・HTTPS・安全なWebSocket通信に同じCA設定が適用されます。証明書検証の無効化で通すのではなく、検証を有効なまま交換が通るかを確認します。HTTP 403だけがある場合に、根拠なくCAを入れ替える手順ではありません。

ブラウザから戻れない場合は、公式の別のログイン経路を使う

この分岐は、ブラウザとCodexが別のホストにある、またはローカルのコールバックが届かない場合に使います。地域・アカウント・管理ポリシーによる拒否を解除する方法ではありません。

デバイスコード認証

公式ガイドは、ヘッドレス環境やコールバックが使えない場合に、ベータのデバイスコード認証を第一候補にしています。個人アカウントではChatGPTのセキュリティ設定、管理ワークスペースでは管理者の権限設定で有効になっている必要があります。

codex login --device-auth

Codexを使うホストのターミナルで実行し、表示された公式リンクをブラウザで開き、同じターミナルに出たワンタイムコードを入力します。他人から渡されたコードは入力しません。設定が無効という案内なら、先に許可の確認が必要です。デバイスコードを選んでも、Codex側の外向き通信や利用資格が拒否されていれば成功しません。

SSHでコールバックを転送する

自分が管理する、または接続を許可されたSSH先で通常のブラウザ認証を使うなら、手元のPCからコールバック用ポートを転送する方法も公式に案内されています。

ssh -L 1455:localhost:1455 user@remote

user@remoteを対象のSSH接続先に置き換え、開いたSSHセッション内でcodex loginを実行します。そのターミナルが表示した認証URLを手元のブラウザで開きます。1455は公式ガイドの既定コールバック用ポートで、プロキシのポート番号ではありません。実際の待ち受けが別のポートなら、同じ転送指定をそのまま使うことはできません。

転送ができたことだけでログイン成功とはせず、Codex側の完了と後述の作業確認まで進みます。コールバックの待ち受けをインターネットへ公開する必要はありません。

自分の認証キャッシュをコピーできる条件

公式ガイドには、ブラウザのあるマシンでログインし、信頼できるヘッドレス機へ自分のファイル形式の認証キャッシュを転送する代替方法もあります。ただし、これは自分のアカウント、許可された転送先、実在するファイル形式のキャッシュが前提です。OSの資格情報ストアに保存されている場合、この方法はそのまま使えません。

既定のCODEX_HOMEを使い、公式に記載された~/.codex/auth.jsonがある場合の転送例は次のとおりです。

ssh user@remote 'mkdir -p ~/.codex'
scp ~/.codex/auth.json user@remote:~/.codex/auth.json

両方のホストで保存先が既定どおりかを先に確認します。独自のCODEX_HOMEや管理側の保存要件がある環境へ、この例を無条件で使わないでください。auth.jsonにはトークンが入っているため、パスワードと同じ扱いが必要です。転送した内容をログやIssueに貼らず、複数のマシンで使い回す運用は公式のCI/CD認証ガイドで更新・保管条件を確認してから判断します。コピーできても、転送先の通信拒否が直った証拠にはなりません。

認証情報を作り直す前に、保存方式と組織の制限を確認する

認証情報が古いという案内があり、許可された方式でサインインし直せる場合は、ファイルを手で探して削除するより、公式コマンドで保存済み認証を消して入り直します。

codex logout
codex login

この操作は現在のログインを解除します。CLIとIDE拡張はログイン情報を共有するため、片方でログアウトするともう片方も再ログインが必要になります。認証キャッシュと保存方式の説明によると、保存方式はfile、keyring、auto、ephemeralで異なります。fileはCODEX_HOME配下のauth.json、keyringはOSの資格情報ストア、autoは利用可能な保存先を選択し、ephemeralは現在のプロセス内だけに保持します。「認証は必ず~/.codex/auth.jsonにある」と考えて全ディレクトリを削除しないでください。

ChatGPTのトークンは通常、利用中に自動更新されます。403だけを理由に毎回ログアウトする必要はありません。また、プロセスの環境がワークロードID（workload identity）を選択している場合、公式ガイドではcodex loginとcodex logoutが拒否されます。人のログインキャッシュではなく、環境を管理する担当者に確認します。

管理ワークスペースでは、ローカル認証の管理要件が認証情報の読み込みより先に適用されます。allowed_login_methods、allowed_chatgpt_workspaces、保存方式、サービスURLの制限は、キャッシュを消しても上書きできません。選べるワークスペースが許可リストに含まれなければChatGPTサインインは利用できず、API認証も許可されている場合に限ります。期待したアカウントやワークスペースを選べないときは、管理者の修正後に同じ対象で再確認します。

APIキーへの切り替えは、元のログインの修復とは別です

APIキーの使用が許可され、OpenAI Platformの課金を承知してローカル作業を続けるなら、公式に別の認証方法があります。既に安全に環境変数へ設定した、自分のキーを標準入力で渡します。

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

公式認証ガイドでは、APIキー利用はPlatformの標準API料金で、ChatGPTプランの利用枠とは別です。Codex cloudにはChatGPTサインインが必要で、一部の機能や適用ポリシーも変わります。キーをコマンドの引数や公開ログに書かないでください。

APIキーで作業が通っても、ChatGPT側のトークン交換403が直ったとは言えません。切り替えが目的に合うかは、CodexのAPIキーとChatGPTサブスクで変わる課金経路を確認します。組織の制限や地域条件を回避するための切り替えは行いません。

復旧は、同じホスト・認証方式・作業で確かめる

ブラウザの成功画面やcodex login statusの0だけで終わらせず、次の順に確認します。

1. 問題が起きたホストでログインが完了する。 SSH先で失敗していたなら、手元のPCだけの成功では不十分です。
2. 期待した認証方式と対象である。 CLIならcodex login status、アプリやIDEなら対象クライアントのアカウント表示を確認します。ChatGPTなら元のアカウント・ワークスペース、APIなら元の送信先・設定をそろえます。
3. 小さな作業で応答を受け取れる。 機密ファイルを含まない作業用ディレクトリで、同じクライアントから「ファイルを変更せず、AUTH_OKとだけ返してください」と依頼します。これは認証済みリクエストが通るかの確認で、利用枠やAPI料金の対象になる場合があります。
4. 元の用途で必要な機能を確認する。 短いテキスト応答だけでは、クラウド機能、ツール実行、長い作業がすべて使えるとは限りません。

途中で401・403が出た場合は、その新しいエラーを別の段階の失敗として記録します。ログイン後のIncorrect API keyならCodexの401をURLと認証方式で見分ける手順、独自プロバイダーでの送信先やキーの不一致ならCodexのカスタムプロバイダー設定が次の確認先です。後者のエラーを、OpenAIのOAuth交換403として扱い続けないでください。

なお、認証先へのHEADリクエストやダミーPOST、モデル一覧の応答は、実際のOAuthコード交換が成功した証明にはなりません。診断用の通信が通ることと、元の認証・作業が通ることは区別します。ここに記載したログイン・転送・API認証のコマンドは公式手順に基づく例で、読者の環境でログイン完了を実測したものではありません。環境変数確認の補助コードは、通信せずに構文を確認しています。

同じ拒否が続くときは、変更した点と結果をサポートへ渡す

地域・アカウント・ワークスペース・組織ポリシーの拒否が明示された場合は、その条件を管理する窓口へ移ります。それ以外でも、根拠のある修正を一つ行い、元の環境で同じ拒否が続いて新しい手がかりがなければ、設定変更を増やすよりログを渡すほうが有用です。

直接codex loginを実行した場合、公式ガイドは、設定されたログ用ディレクトリのcodex-login.logを診断に使うよう案内しています。保存先を確認し、必要なエラー周辺を秘密情報を除いて共有します。全ログやauth.jsonをそのまま添付しないでください。

発生日時とタイムゾーン: <実際の日時>
クライアントとバージョン: <CLI / アプリ / IDE、版>
実行環境: <ホスト / WSL / コンテナ / SSH先>
認証方式と対象: <ChatGPT / API、対象ワークスペース>
失敗した段階: <コールバック / 交換 / 保存 / 作業>
エラー: <全文から秘密情報を除いたもの>
応答: <短いコード、request ID、秘密を除いた本文>
通信経路: <直接 / 承認済みプロキシ / 企業TLS検査 / 不明>
変更した点: <一つの修正>
再確認の結果: <同じ403 / ログイン完了 / 小さな作業も成功>

企業ブロックの手がかりがあればネットワーク担当者へ、認証方式やワークスペースの制限なら管理者へ、説明できないアカウント側の拒否ならOpenAI Help Centerへ渡します。コールバックURL、トークン、キー、Cookie、プロキシの認証情報は、この記録にも含めません。

よくある質問

ブラウザではログイン成功なのに、Codexで403になるのはなぜですか？

ブラウザでの本人確認と、Codex側のトークン交換は別の段階だからです。CLIが待ち続けるならコールバック到達、交換403が明示されるなら応答本文とCodex実行ホストの通信を確認します。ブラウザの画面だけでは、Codexが認証情報を保存できたかも分かりません。

デバイスコード認証に変えれば403は直りますか？

コールバックが届かない問題には使える選択肢ですが、すべての403には効きません。公式のヘッドレス認証手順が前提とする設定・管理者の許可が必要で、外向き通信、地域、アカウントや組織の拒否は別に確認します。

auth.jsonを削除すればいいですか？

最初の対処にはしません。保存先はファイルとは限らず、組織の制限や通信拒否は消しても変わりません。再ログインが必要という根拠があり、許可された認証方式で入り直せる場合に、codex logoutとcodex loginを使います。workload identityが選ばれている環境では、そのコマンドではなく環境の管理者が確認します。

codex login statusが0なら復旧済みですか？

いいえ。CLIリファレンスでは、0は認証情報の存在を示します。同じホスト、元の認証方式・ワークスペースで、小さな認証済み作業が成功したことまで確認してください。APIキーに切り替えて成功した場合は、ChatGPTの交換403が修復された証拠にはなりません。