# CodexのToken Exchange Failed：ログインの失敗段階から直す > Codexのtoken exchange failedとaccess token更新エラーを、OAuth交換・ローカルループバック・実行ホストに分け、安全に再認証する手順。 - Source: https://www.aifreeapi.com/ja/posts/codex-access-token-could-not-be-refreshed - Language: ja - Published: 2026-08-25 - Updated: 2026-08-31 - Publisher: AI Free API (https://www.aifreeapi.com) `Token exchange failed` と `Your access token could not be refreshed` は、どちらも Codex の認証エラーですが、発生段階が違います。前者はブラウザ認可の結果を token に交換する途中、後者は既存セッションの更新時です。OpenAI は、この文言だけから一つの原因を確定できる完全なエラー対応表を公開していません。 ブラウザに成功画面が出ても、Codex プロセスがローカルループバック callback を受け取り、token endpoint に到達し、認証情報を保存できたとは限りません。まず **Codex が動くホストと、最後に成功した認証段階** を一致させてください。 ## エラー末尾で最初の確認先を決める 完全なエラー文を残し、秘密情報だけをマスクします。末尾の違いで、調べる境界が変わります。 | 見えているシグナル | ここまで分かること | 最初の確認 | |---|---|---| | `error sending request for url (.../oauth/token)`、timeout、connection error | Codex プロセスから token endpoint への要求が完了していない | ブラウザではなく実行ホストの network、proxy、TLS | | `token endpoint returned status 403` | endpoint は要求を受け取ったが拒否した | status とマスク済み文脈を残し、account、workspace、管理ポリシーを確認する | | ブラウザ完了後も CLI が待ち続ける | ローカルループバック callback が Codex に届いていない可能性がある | WSL、SSH、container、remote extension host のどこで動くか | | `access token could not be refreshed` | 保存済みセッションの更新に失敗した | 実行環境で auth status を確認し、対応コマンドで認証情報を作り直す | | `CERTIFICATE_VERIFY_FAILED` などの明示的な CA エラー | プロセスが証明書チェーンを信頼できない | 既知の企業 TLS proxy／private CA がある場合だけ CA bundle を確認する | 403 は「拒否された」証拠であり、地域、VPN、アカウント、サブスクリプションのどれが原因かを単独では示しません。 ![Codex 認証の exchange callback refresh を分け、実行ホスト、CLI 再ログイン、device code、SSH、企業 TLS、復旧証拠、安全なサポート情報を整理した日本語図](https://www.aifreeapi.com/posts/ja/codex-access-token-could-not-be-refreshed/img/oauth-stage-host-recovery.webp) ## ログアウト前に作業を保全する 認証エラーで、すでに書き込まれたファイルが自動的に消えるわけではありません。危険なのは、複数の App や IDE で同じタスクを再実行したり、「キャッシュ削除」のつもりでプロジェクトまで消したりすることです。 先に次を残してください。 - リポジトリ内の未コミット変更 - 個人情報を除いた完全なエラー文 - 発生時刻とタイムゾーン - Codex App、CLI、IDE のどこで発生したかとバージョン - プロジェクトパスと最後に成功した操作 `auth.json` の内容、access token、refresh token、API key、OTP、Cookie、未処理の HAR は共有しません。OpenAI の[認証ドキュメント](https://learn.chatgpt.com/docs/auth#credential-storage)では、ファイル保存の `auth.json` にアクセストークンが含まれるため、パスワード同様に扱うよう案内しています。 ## 画面ではなく実行ホストを確認する ローカル画面にエラーが出ても、認証情報がローカルにあるとは限りません。VS Code のウィンドウは手元の Mac や Windows にあっても、extension host は Remote SSH 側かもしれません。ターミナルが WSL や dev container の中なら、Codex はその環境の home や keyring を使います。 | 利用面 | 最初に確認する場所 | よくある取り違え | |---|---|---| | Codex App | App の現在のプロフィールとローカル認証ストア | 別ブラウザの ChatGPT だけログアウトする | | Codex CLI | その shell の OS ユーザーと `CODEX_HOME` | Web 版が使えるので CLI も正常だと考える | | IDE 拡張 | extension host が local か remote か | エディタ UI だけ再インストールする | | WSL、SSH、container、VM | 環境内の home または keyring | ホスト PC だけでログアウトする | | 外部 harness | そのツール固有の認証 profile | 単体 CLI の成功を全ツールに当てはめる | 公式資料によると、Codex CLI と IDE 拡張は保存済み認証情報を共有する場合があります。保存先は `~/.codex/auth.json` または OS の資格情報ストアです。したがって、推測でファイルを削除するより、まずサポートされる logout を使う方が安全です。 ## CLI と IDE の認証情報を作り直す エラーを出した Codex が動く環境で、現在の方式を確認します。 ```bash codex login status ``` このコマンドは認証情報の有無と active authentication mode を表示します。ChatGPT プランを使っているつもりでも API key 認証になっている、Remote SSH 先が別の OS ユーザーになっている、といったずれを発見できます。ただし status が成功しても、モデルへの実リクエストまで成功する保証にはなりません。 保存済み認証情報を消してログインし直します。 ```bash codex logout codex login ``` ブラウザでは、利用したい ChatGPT アカウントと workspace を確認して完了します。その後、もう一度 `codex login status` を実行します。 OpenAI の[認証ドキュメント](https://learn.chatgpt.com/docs/auth#check-authentication-or-sign-out)は、`codex login`、`codex login status`、`codex logout` を案内しています。CLI と IDE がキャッシュを共有していても、起動中の extension host が古い状態を持つことがあるため、再ログイン後は IDE を完全に終了して開き直します。 Codex App ではプロフィールメニューで現在のアカウントまたは API key の状態を確認し、App 内からログアウトします。App を完全終了してから再起動し、意図した方式でログインしてください。ブラウザの `chatgpt.com` だけをログアウトしても、App のローカル認証情報が消えた証拠にはなりません。 ## 新しいログインが完了しない場合 古い認証情報を消した後、ブラウザから Codex へ戻れないなら、元のトークン更新問題とは別の段階です。 Remote SSH や headless 環境ではローカルのコールバック先へ戻れないことがあります。アカウントまたは workspace で許可されている場合は device code を使います。 ```bash codex login --device-auth ``` 表示されたリンクを開き、ログイン後に一回限りの code を入力します。code を他人に送らないでください。機能が無効なら、個人設定または workspace 管理者による許可が必要です。 通常の browser flow を維持し、CLI が SSH 先で動いている場合、公式の既定 callback はローカルループバックの 1455 番ポートです。ローカル側から転送し、同じ SSH session でログインします。 ```bash ssh -L 1455:[::1]:1455 user@remote codex login ``` 1455 をインターネットに公開しないでください。ローカル CLI に機械的に追加する必要もありません。この tunnel が直すのは callback 経路だけで、endpoint 403 や証明書エラーは直しません。 企業ネットワークの TLS proxy や private root CA が原因なら、公式ガイドは信頼済み PEM bundle を指定する `CODEX_CA_CERTIFICATE` を案内しています。また、直接実行した `codex login` は設定済みログディレクトリに `codex-login.log` を書きます。callback、証明書、ブラウザ認証を切り分ける材料になりますが、共有前に token、メール、workspace ID、非公開パスを削除します。 管理環境では ChatGPT または API key の方式が強制され、特定 workspace に限定されることがあります。新しいアカウントがすぐ拒否される場合は、ローカルファイルを繰り返し消さず、管理者に membership、provisioning、許可された方式、対象 workspace を確認します。 workload identity を使う実行環境では、認証はプロセス環境から与えられます。公式資料では、この場合の `codex login` と `codex logout` は拒否されます。修復対象はユーザーキャッシュではなく、identity provider、federation rule、runtime 設定です。 ## 小さな実タスクで復旧を判定する 復旧完了はログイン画面ではなく、次の三つで判断します。 1. `codex login status` が意図した方式を示す。 2. App または IDE が、表示可能な範囲で正しいアカウントと workspace を示す。 3. 元と同じプロジェクト・実行環境で、小さな低リスクのタスクが完了する。 最初は機密性のない一ファイルを読み取り要約する程度にします。すぐに大規模な書き込みを再開せず、既存の変更を確認してから元のタスクへ戻ります。 ![Codex 復旧完了を login status、正しいアカウントと workspace、小さな実タスクの成功で判定し、サポートへ渡す情報と添付しない秘密を整理した日本語チェックリスト](https://www.aifreeapi.com/posts/ja/codex-access-token-could-not-be-refreshed/img/recovery-proof-checklist.webp) 別のエラーになったら診断も切り替えます。HTTP 429 は [Codex のレート制限](/ja/posts/codex-rate-limits)、接続やツールの停止は [Codex タイムアウト](/ja/posts/codex-timeout)、電話番号・MFA・device verification は [Codex の認証確認](/ja/posts/codex-phone-verification)の対象です。 ## サポートへ渡す情報 正しい実行ホストで新規ログインしても同じ更新エラーが出る場合は、秘密情報ではなく再現条件を渡します。 - マスク済みエラー文、時刻、タイムゾーン - App、CLI、IDE とバージョン - OS、および local、WSL、SSH、container、VM の別 - token や完全なアカウント ID を含まない認証方式 - logout と新しい browser/device flow の結果 - 小さな確認タスクの結果 - 新規ログイン自体が失敗した場合だけ、消毒済み `codex-login.log` の抜粋 `auth.json`、token、API key、OTP、Cookie、完全な HAR、未加工スクリーンショットは添付しません。正しいホストの新しい認証情報が意図したアカウントと方式に結び付き、境界の小さい Codex タスクを完了して初めて復旧です。