ある日、にCodex CLI を WSL 環境で使っていたところ、突然 codex login が通らなくなりました。
結論から言うと、codex login だけ失敗する場合は、Codex CLI や Node.js を入れ直す前に、api.openai.com と auth.openai.com を分けて確認したほうがよさそうです。
今回のケースでは、api.openai.com には到達できていた一方で、auth.openai.com への認証通信だけが Cloudflare 側で Bot 判定されていた可能性が高そうでした。回避策としては、スマホテザリングなど別回線に切り替えて codex login し、ログイン後に元の Wi-Fi に戻す方法が有効でした。
つまり、「Codex CLI は入っているのに login だけ失敗する」ときは、まず認証エンドポイント側のネットワーク評価を疑うのが近道です。
前日に Wi-Fi ルーターを交換していたので、最初はかなりネットワーク周りを疑いました。結果としても、その見立てはそこまで外れていなかったようです。
以下、そのときの切り分けメモです。
環境
今回の環境は以下です。
- Windows 11
- WSL2 / Ubuntu
- Codex CLI
- Node.js / npm / nvm
- 前日に Wi-Fi ルーターを交換
Codex CLI 自体は以前から使えていました。つまり、初回セットアップではなく、ある日突然ログインまわりだけが壊れたケースです。
発生したこと
WSL で codex login を実行すると、以下のようなエラーで失敗しました。
Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token)
codex login --device-auth でも同様に失敗しました。
一方で、Codex CLI のインストール自体や codex --version は動いていました。なので、最初から「Codex CLI が壊れている」というより、認証のどこかで詰まっている雰囲気でした。
最初に疑ったこと
前日に Wi-Fi ルーターを交換していたので、まずはそこを疑いました。
具体的には以下の可能性です。
- ルーター交換でグローバル IP が変わった
- 新しい回線経路や IP 評価が Cloudflare 側で怪しく見えている
- WSL からの通信だけ何かおかしい
- DNS や IPv6 周りで変な経路になっている
ただし、すべての通信が失敗しているわけではありませんでした。
切り分け
まず、OpenAI の API 側と認証側を分けて確認しました。
api.openai.com は到達できる
curl -I https://api.openai.com/v1/models
未認証なので 401 になりますが、API 側には到達できていました。
つまり、OpenAI 全体につながらないわけではありません。
auth.openai.com で詰まる
問題は auth.openai.com 側でした。
codex login の token exchange が失敗しており、curl で確認しても Cloudflare の challenge / 403 系の反応が出ていました。
この時点で、少なくとも以下のように整理できます。
| 対象 | 結果 |
|---|---|
api.openai.com |
到達できる |
auth.openai.com |
認証処理で失敗 |
codex --version |
動く |
codex login |
失敗 |
codex login --device-auth |
失敗 |
ここで重要なのは、API 利用の通信とログイン認証の通信は別物 という点です。
原因の見立て
今回の直接原因は、auth.openai.com への CLI 通信が Cloudflare に Bot っぽく見えてブロックされたことだと考えています。
推定ですが、判定要因としてはこのあたりがありそうです。
- CLI / curl / Node.js からのアクセス
- ブラウザのように JavaScript を実行しない
- Cookie やブラウザ文脈がない
- localhost redirect を伴う OAuth
- IP アドレスの評価
- 直前に Wi-Fi ルーター交換でネットワーク条件が変わった可能性
もちろん、Cloudflare の判定ロジックは外から正確にはわかりません。なので「これが絶対原因」とは言えません。
ただ、今回の現象としては、Codex CLI や Node.js の壊れ方というより、認証エンドポイントだけがネットワーク評価で弾かれている挙動に見えました。
類似の報告
調べてみると、似たような現象の報告もありました。
Codex CLI の GitHub issue
この issue では、codex login と codex login --device-auth の両方が token_exchange_failed で失敗し、auth.openai.com に対して Cloudflare の JavaScript challenge が返っている、という内容が報告されています。
特に近いのは以下の点です。
-
codex loginが失敗する -
codex login --device-authも失敗する -
auth.openai.com側で Cloudflare challenge / 403 が返る - CLI の HTTP クライアントでは challenge を解けない
- ブラウザでの OAuth 途中までは進んでも、CLI 側の token exchange で詰まる
今回の自分の現象とかなり近いので、これは類似事例として見てよさそうです。
Reddit / OpenClaw 側の報告
こちらは Codex CLI そのものではなく、OpenClaw の openai-codex プロバイダーまわりの話です。
そのため完全に同じ事象とは言い切れません。対象エンドポイントも auth.openai.com ではなく、chatgpt.com/backend-api 側の話が中心です。
ただし、以下の点では近いです。
- OAuth トークン自体の有効性とは別に、非ブラウザHTTPクライアントが Cloudflare に弾かれる
- ブラウザではなく CLI / agent / HTTP クライアントからのアクセスが問題になる
- 再認証や再インストールでは解決しないケースがある
- Cloudflare の bot mitigation がエッジで先に効いて、アプリ側の認証処理まで届かない
なので、こちらは「同じ現象」とまでは言わず、同じ系統の問題が別ツールでも起きている例 として触れるのがよさそうです。
今回の記事では、OpenClaw の詳細には踏み込みすぎず、「Cloudflare による OAuth / 非ブラウザクライアントのブロックは、他のツールでも報告されている」くらいの扱いにしておきます。
解決した方法
今回は、スマホのテザリングに切り替えて codex login を実行したところ、ログインできました。
手順としては以下です。
# 1. PC のネットワークをスマホテザリングに切り替える
# 2. WSL で Codex CLI にログイン
codex login
# 3. ログインできたら通常の Wi-Fi に戻す
codex login status
ログイン後は、元の Wi-Fi に戻しても通常利用できました。
これは、Codex CLI の利用時に毎回 auth.openai.com でログインするわけではなく、通常の推論や API 利用は別の経路で動くためだと思います。
後から再確認したこと
少し時間を置いて同じ通常回線から再確認したところ、auth.openai.com が Cloudflare 403 ではなく、OpenAI の OAuth 処理まで到達する状態になっていました。
例えば、ダミー値で token endpoint に POST すると、Cloudflare 403 ではなく Missing 'client_id' のような OAuth 側のエラーになりました。
つまり、今回のネットワークが恒久的にブロックされているというより、IP 評価や時間帯、接続直後の状態などで一時的に判定が変わった可能性があります。
このあたりは少し気持ち悪いですが、Cloudflare 絡みのトラブルとしてはよくあるタイプだと思います。
(うまくいかなかった)Windows 側でログインする案
別案として、Windows 側で Codex CLI にログインして、auth.json を WSL 側にコピーする方法も考えました。
イメージとしては以下です。
codex login
codex login status
Windows 側でログインできたら、WSL 側に認証情報をコピーします。
cp /mnt/c/Users/<user>/.codex/auth.json ~/.codex/
chmod 600 ~/.codex/auth.json
codex login status
ただし、今回の自分の環境では Windows 側の Codex CLI 起動自体がまだうまく整理できていなかったため、この方法は未確立です。
PowerShell で codex.ps1 が実行ポリシーに止められる場合もあるので、その場合は cmd から codex.cmd を試すのがよさそうです。
where node
node --version
where codex
codex.cmd --version
やらなくてよさそうだったこと
今回の切り分けでは、以下は本質ではなさそうでした。
- Codex CLI の再インストール
- Node.js の再インストール
- npm / nvm の入れ直し
- モデル設定の変更
もちろん環境によっては必要なケースもあると思いますが、少なくとも今回の主因はそこではなさそうでした。
api.openai.com は到達できていて、auth.openai.com の token exchange だけが失敗していたためです。
私は色々とやってしまって、既存の環境を壊してしまい、自動化環境の復旧がさらにややこしく…。
再発したときのチェックリスト
次に同じことが起きたら、以下の順で見るのがよさそうです。
1. Codex CLI 自体が動くか
codex --version
2. ログイン状態を見る
codex login status
3. API 側に到達できるか
curl -I https://api.openai.com/v1/models
401 なら、未認証ではあるものの API 側には到達できています。
4. 認証側に到達できるか
curl -I https://auth.openai.com/oauth/token
ここで Cloudflare 403 や challenge っぽい反応になる場合、CLI の OAuth が弾かれている可能性があります。
5. 別回線でログインする
スマホテザリングなど、別のネットワークで試します。
codex login
codex login status
ログインできたら、元の回線に戻して通常利用できるか確認します。
まとめ
今回のポイントです。
-
codex loginだけ失敗する場合、Codex CLI 本体ではなく認証経路を疑う -
api.openai.comとauth.openai.comは分けて確認する -
auth.openai.comだけ Cloudflare 判定で弾かれることがある - Wi-Fi ルーター交換や IP 変更の直後は、ネットワーク評価が変わる可能性がある
- 一時的な回避策として、スマホテザリングでログインするのは有効だった
- ログイン後は通常回線に戻しても利用できた
個人的には、「CLI の OAuth はネットワーク評価にけっこう影響される」というのが今回の学びでした。
普段はトークンが生きているので問題が見えませんが、トークン期限切れや再ログインのタイミングで急に表面化します。
環境を入れ直す前に、まずは api.openai.com と auth.openai.com を分けて見るのがよさそうです。