Token exchange failed: token endpoint returned status 403 Forbidden は、認証交換のリクエストが拒否されたことだけを示します。OpenAI全体の障害、プロキシ、地域制限、古い認証情報のどれが原因かは、この文字列だけでは決まりません。まず、localhostへのコールバック、外向きのトークン交換、ログイン後の最初の認証済みリクエストを分けてください。リセットする前に codex --version と codex login status を記録し、Codexが実際に動く環境と、秘密を除いたレスポンス本文を残します。拒否箇所が不明な間は、~/.codexの全削除、TLS検証の無効化、地域制限の回避、コールバックURLやトークンの共有を行わないでください。
| 見えた症状 | 失敗した段階 | 最初に確かめること |
|---|---|---|
| ブラウザからCodexに戻らない | localhostコールバック | ブラウザと待受プロセスが到達可能な同じ環境にあるか |
| ブラウザ認証後、正確な交換403が出る | 外向きトークン交換 | 本文、プロキシ/WAF、CA、地域・アカウント、実行環境 |
| ログイン完了後、最初の操作で403になる | 認証済みリクエスト | ワークスペース権限、モデル、プロバイダー、認証元 |
コールバック障害とtoken endpointの拒否は別物です。後続のAPI 403も交換失敗ではありません。レスポンスがアカウント、ワークスペース、ポリシー、対応地域を明示したら、プロキシ変更を止めてその管理者へ移します。
“2026年7月12日確認: OpenAI Statusに既知の全体障害は表示されていませんでした。緑の表示は、個別ネットワークやアカウント経路の正常性を保証しません。
最初の7分で行う確認
1. 同じ実行環境で状態を採る
bashcodex --version codex login status
問題が起きたmacOS、Windows、Linux、WSL、コンテナ、SSH先、IDEターミナルで実行します。検証環境の codex-cli 0.144.0-alpha.4 は観測例であり、最低要件ではありません。
2. サービス状態と時刻を記録する
OpenAI Statusに認証またはCodexの障害があれば、ローカル設定を変えずに復旧を待ちます。障害がなければ、企業ネットワーク、CA、アカウント、実行環境の確認へ進みます。
3. Codexの実行主体を特定する
ブラウザはホストOS、CodexはWSLやリモートサーバーという構成があります。ブラウザが待受へ届かないならコールバックの問題です。Codexがコールバックを受けた後でtoken endpoint 403を出したなら、外向き交換の経路を調べます。
4. レスポンスを安全に保存する
正確なエラー、日時とタイムゾーン、バージョン、コマンド、短いエラーコード、request IDを残します。authorization code、access/refresh token、完全なcallback URL、Cookie、API key、メール、組織ID、プロキシ認証情報は削除します。
5. 1回だけクリーンに再試行する
Codexの更新、許可済みネットワーク、正しい実行環境、承認済みCA、ログイン状態のうち1つだけ変更します。成功は同じ環境の codex login status と、小さな認証済み操作の両方で確認します。
認証を5段階に分ける
流れは、ブラウザ認証、localhostコールバック、コードとトークンの交換、認証情報の保存、最初の認証済みリクエストです。対象のエラーは3段階目に属します。拒否元はOpenAIのアカウント・ポリシー、企業プロキシ/WAF、TLS inspectionとCA、誤った実行環境、古い認証コンテキストのいずれもあり得ます。
Codex認証ドキュメントはログイン方式と保存方法の基準です。環境変数リファレンスには承認済みCAバンドル用の CODEX_CA_CERTIFICATE が記載されています。TLS検証を切る代わりに正式な信頼設定を使います。
証拠から分岐を選ぶ
| 分岐 | 根拠 | 操作 | 成功条件 | 中止条件 |
|---|---|---|---|---|
| プロキシ/WAF | 企業ブロック画面、proxy ID | ネットワーク管理者へ認証経路の許可を依頼 | 許可経路で1回のログインが完了 | 組織ポリシーを迂回しない |
| 企業CA | 証明書チェーンエラーとTLS inspection | 承認PEMを設定 | 検証を有効にしたまま交換成功 | insecure TLSを使わない |
| WSL/コンテナ/remote | ブラウザと待受が別ネットワーク | コールバック到達可能な場所でログイン、または公式代替方式 | 同じCodexプロセスが受信 | 待受を公開しない |
| 地域・アカウント | unsupported_country_region_territory 等 | 対応国・地域を確認し、誤判定はSupportへ | 公式経路が利用可能 | VPNや借用アカウントで回避しない |
| ワークスペース | 個人経路は成功、SSOは拒否 | 管理者にCodex権限とidentity policyを確認 | 対象ワークスペースで成功 | ポリシー明示後はローカル変更を止める |
| 認証キャッシュ | 経路とポリシーは正常、logoutで挙動変化 | codex logout 後に1回だけ codex login | 期待方式と操作が成功 | 最初から全ディレクトリを消さない |
プロキシではlocalhostと外向きを分ける
プロキシ必須環境でもloopbackは通常ローカルに保ちます。
bashexport NO_PROXY="localhost,127.0.0.1,::1"
一方、外向きtoken endpointは承認済み企業プロキシを通す必要があるかもしれません。OpenAI関連ドメインを一括で NO_PROXY に入れないでください。企業TLS inspectionが確認できる場合だけ、セキュリティ部門のPEMを使います。
bashexport CODEX_CA_CERTIFICATE="/path/to/company-ca-bundle.pem" codex login
認証レイヤーだけをリセットする
bashcodex logout codex login
rm -rf ~/.codex から始めると設定、状態、診断材料まで消えます。各ファイルの役割は Codex config.tomlガイドで確認できます。別ユーザーの auth.json をコピーしたり、自分のファイルをIssueへ添付したりしないでください。
2026年7月12日に確認したCLIには --device-auth、--with-api-key、--with-access-token があります。device authはブラウザとlocalhostの接続問題には有効ですが、地域やアカウントポリシーを越えません。API keyは開発者課金の別経路なので、CodexのAPI keyとサブスクリプションで境界を確認します。
症状ごとに次の一手を決める
ブラウザは成功画面、ターミナルは待機したまま
token endpointの403より前に、callbackがCodexへ届いていない可能性が高い状態です。ブラウザとCodexが同じマシンか、WSL・コンテナ・SSH先に分かれていないかを確認します。ブラウザの「成功」はユーザー承認の完了であり、ローカルプロセスが結果を受信した証明ではありません。
ホスト側でログインをやり直す、またはCLIが明示的に対応するdevice authを使う判断はできます。ただし、localhostの待受ポートをインターネットへ公開したり、callback URLをチャットで共有したりしてはいけません。
ターミナルにtoken endpoint 403が明示される
callback後の外向き交換に焦点を移します。レスポンスがOpenAI形式のJSONか、企業プロキシのHTMLか、短いテキストかを確認してください。企業ロゴ、block ID、社内サポート先があるHTMLならネットワーク層の証拠です。同じpolicy codeがネットワークを変えても続くなら、アカウントや地域の所有範囲が濃くなります。
最後の 403 Forbidden だけを切り取ると、この差が失われます。秘密を削除した本文、request ID、時刻を一組にして残します。レスポンスがworkspaceやaccountを明示した後にCookie削除を続けても、管理側の条件は変わりません。
証明書エラーと403が混在する
発生順を分けてください。TLS handshakeが失敗している間は、OpenAIのHTTP 403まで到達していないことがあります。承認済みCAを設定してhandshakeが通った後、別のJSON 403が残るなら、CA問題は解決し、別の分岐が残ったということです。
ネットワーク担当者にはTLS inspectionの有無、配布すべきroot CA、認証先の許可状態を確認します。フォーラム由来の証明書や NODE_TLS_REJECT_UNAUTHORIZED=0 のような全体無効化は使いません。
WSL・コンテナ・SSHだけで失敗する
ホストでは成功し隔離環境だけで失敗するなら、実行環境の差が強い証拠です。それぞれでバージョン、proxy変数、NO_PROXY、CA変数、ログイン状態を比較します。コンテナが再起動ごとに認証状態を失う問題と、交換時に403になる問題も分けて扱います。
ホストの auth.json を隔離環境へコピーする方法は避けます。トークン漏えいだけでなく、隔離環境に残るネットワークや保存先の問題を隠してしまうためです。
Business・Enterprise・SSO経路だけで失敗する
ブラウザに複数アカウントが残っている場合、意図しない個人アカウントや組織を選んでいないか確認します。管理者はCodexの有効化、メンバー資格、SSO強制、条件付きアクセス、identity mappingを確認します。個人経路が成功しても、管理ワークスペースの権限を証明しません。
管理者が修正した後は、同じワークスペースと同じ実行環境で一度だけ再ログインします。別アカウントへ逃げると、修正確認になりません。
交換後の最初のリクエストだけが403
codex login statusで認証情報が保存済みか確認し、その後のレスポンスを別件として読みます。モデル権限、組織entitlement、API互換プロバイダー、環境変数のAPI keyが原因かもしれません。OAuthとAPI keyの両方が設定されている場合は、どの認証元が優先されたかも記録します。
再現記録は短い時系列にする
text日時/タイムゾーン: 2026-07-12 17:20 +08:00 OS/実行環境: host / WSL / container / SSH Codex version: <出力> 認証方式: ChatGPT / device auth / API key / access token callback: 到達 / 未到達 / 不明 exchange: status、脱敏code、request_id network: direct / corporate proxy / TLS inspection 変更した点: 1つだけ 結果: 同じ403 / login完了 / 後続リクエスト失敗
この形なら、どの段階が変わったかを管理者やSupportが追えます。ブラウザ、ネットワーク、アカウント、Codex versionを同時に変えると、成功しても原因を特定できません。
避けるべき操作は、ログイン連打、ブラウザとCodex状態の同時全削除、全OpenAIドメインの NO_PROXY 追加、VPNによる地域回避、未脱敏ログの公開、第三者APIプロバイダーの403をOpenAI OAuthと同一視することです。試行回数ではなく、1回の試行で1つの所有範囲を除外できたかを基準にします。
Supportへ渡す証拠
ポリシー、アカウント、ワークスペース、地域が本文に出たら直ちにエスカレーションします。それ以外は、現行ビルドと許可経路で1回再試行して同じ証拠が出た時点です。エラーと脱敏した本文、時刻、バージョン、認証方式、OSと実行環境、callback結果、proxy/WAF/TLSの有無、request IDまたは /feedback ID、1つの変更と結果を共有します。
callback URL、authorization code、token、API key、Cookie、完全な auth.json、認証情報付きproxy URLは共有しません。ログイン後の利用量問題は Codex利用上限へ切り分けます。
よくある質問
ブラウザが成功してもCodexが失敗するのはなぜですか？
ユーザー認証とコード交換は別の通信です。後者だけがプロキシ、ポリシー、アカウント条件で拒否されることがあります。
OpenAIドメインをNO_PROXYに入れるべきですか？
一律には入れません。loopbackをローカルにしつつ、外向き交換は企業ルールに従います。
API keyに変えれば直りますか？
適切な開発者認証にはなりますが、課金と機能が変わり、アカウント・ワークスペース・地域ポリシーは回避できません。
ローカル調査を止める時点は？
明示的なpolicy/account/workspace/region拒否が出た時、または許可経路で1回のクリーン再試行が同じ結果になった時です。