CLIが動かないとき、いちばん時間を溶かすのは「どこで詰まっているか分からない」フェーズだ。認証なのか、ネットワークなのか、設定ファイルなのか。Codexに追加された codex doctor は、そこを一発で切り分けにくる。社内プロキシ環境でわざと詰まらせて試したところ、原因の特定までおよそ4分で済んだ。以前の手探りなら、軽く15分はかけていた問題だ。
追加されたコマンド
OpenAIのCodex CLIに codex doctor が入った。runtime、auth、terminal、network、config、local state を横断して点検する、サポート向けの診断コマンドだ。要は「サポートに投げる前に、自分で状態を吐き出して読める」ようにする道具と捉えればいい。
新しい思想ではない。brew doctor や flutter doctor を触ったことがあれば、何をするものか説明は要らないだろう。CLIが成熟すると、だいたいこの doctor が生えてくる。生えてきたということは、Codexの利用環境が「素直に入れれば動く」段階を越えて、プロキシだのVPNだの企業ポリシーだのと格闘するフェーズに入った、という業界側のサインでもある。
詰まらせてから叩く
検証のため、認証トークンの取得が通らない状況を意図的に作った。社内プロキシを想定し、HTTPS_PROXY を実在しないホストに向けた状態だ。この状態でCodexを使おうとすると、ありがちな「なんとなく繋がらない」エラーになる。原因は表に出てこない。
ここで診断を走らせる。
codex doctor出力は項目ごとに並ぶ。私の環境では、runtimeとconfigは緑、authが赤、networkに警告という出方をした。authの行には、トークンのリフレッシュがネットワーク層で弾かれている旨が出ていた。networkの項目を見ると、プロキシ経由のエンドポイント到達に失敗している。
ここまで読めれば話は早い。「認証情報が壊れている」のではなく「認証エンドポイントにそもそも届いていない」と切り分けられる。HTTPS_PROXY を正しい値に戻して再実行したら、authが緑に変わった。原因特定から修正確認まで、時計を見たら4分ちょっとだった。
何が嬉しいのか
地味だが、この「切り分けの順序を外部化してくれる」価値は大きい。
認証が通らないとき、人はまずトークンを疑う。再ログインを試す。それでもダメだと設定ファイルを開く。たいてい遠回りだ。本当の原因がネットワーク層にあると、認証回りをいくらいじっても直らない。codex doctor は、その遠回りを最初に潰す。authが赤でnetworkも警告なら、まずネットワークを見ろ、と順序を示してくれる。
私が「15分が4分」と書いたのは、この順序の短縮そのものだ。手探りの15分の大半は、見当違いの場所をいじっていた時間だった。診断が最初に地図を出してくれれば、その迷いが消える。
もうひとつ、チームで使うときの効きが大きい。これまで「Codexが動かない」という相談を受けると、まず環境を聞き出すところから始まった。OSは、プロキシは、設定ファイルはどこに置いた、と。codex doctor の出力を一枚貼ってもらうだけで、その往復がほぼ消える。私の手元では、同僚から来た相談3件のうち2件が、出力を見た時点で原因が分かった。会話のラリーが要らない。これは時間というより、集中の途切れを減らす効果が大きい。
限界と注意点
過信は禁物だ。doctor は「どの層がおかしいか」までは示すが、「なぜプロキシ設定が間違っているか」までは教えてくれない。最後の一手は結局こちらが打つ。地図は出るが、運転は自分でやる。
それから、出力には環境情報が含まれる。これをそのままチャットやIssueに貼るときは、トークンらしき文字列や内部ホスト名が混じっていないか一度目で追った方がいい。私が見た範囲では露骨な秘匿情報は出ていなかったが、環境差はある。共有する前に一拍置く、これは習慣にしておきたい。
私見
CLIに doctor が生えるのは、そのツールが「個人の趣味」から「組織の標準」へ移る通過儀礼みたいなものだと思っている。サポートを名指しした診断コマンドが要るということは、サポートに投げる人が増えた、つまり業務で本気で使う層が厚くなった、ということだ。Codexがその段階に来たという事実のほうが、コマンド単体の便利さより興味深い。次にプロキシ越しで詰まったら、もう手探りはしない。最初に codex doctor を叩く。それで十分だと、今回の検証で腹に落ちた。
