Codex CLIの認証をChatGPTに固定する―forced_login_methodでAPI認証経路を制限する

コメントをきっかけに認証経路を確認しました#

今回のきっかけは、Codexの上限到達後にOpenAI API側の利用が発生していた、というコメントです。

コメントでは、Codex CLIとclaude -pを並行で実行していたとのことでした。上限到達後の挙動に不安を感じ、ルーター側で通信を止めたとも書かれていました。

ここで切り分けておきたいのは、確認できている事実の範囲です。

確認できているのは、「Codexの上限到達後にAPI側の利用が発生していた」というコメントを頂いたことです。上限到達の瞬間にCodex CLIが自動でAPI認証へ切り替わったことまでは確認できていません。

Codex CLIの認証状態、API Platform側の利用開始時刻、実行中プロセスへ渡されていた環境変数などがそろっていれば、もう少し細かく切り分けられます。今回はそこまでの記録がないため、記事内でも自動切り替えを事実として扱いません。

そのうえで、「API認証を使わせたくない場合、Codex側で制限できるのか」を調べました。

ChatGPT経由とAPI経由は請求の仕組みが分かれています#

OpenAIの案内では、ChatGPTアカウントでCodexへサインインした場合、ChatGPTプラン側の利用枠と請求体系が適用されます。

一方、利用者が用意したAPIキーを使う場合はOpenAI APIの料金が適用されます。

ChatGPTとAPI Platformは請求管理も分かれています。API Platform側で発生した利用料金は、ChatGPTの月額料金とは別に管理されます。

利用経路	主な認証	確認する場所
ChatGPT側	ChatGPTログイン	Codexの/status、ChatGPT側の使用状況・クレジット
API側	APIキー等	API PlatformのUsage / Billing

Codexの利用枠が少なくなったときは、実行中のCodex CLIで/statusを入力すると現在の利用状況を確認できます。

また、現在のChatGPTプランでは、対象プランでCodexの利用枠を使い切ったあと、追加クレジットを購入して利用を続けられる場合があります。このクレジット消費もAPI Platformの従量課金とは分けて確認する必要があります。

ゆまラボでは以前、CodexのLunaとAstraを実作業で比較した記事でも利用枠の減り方を確認しています。長時間の自動実行を行う場合は、開始時だけ確認するより、途中でも/statusを見る方が状況を把握しやすくなります。

forced_login_methodでCodexの認証方法を固定できます#

OpenAIのCodex設定リファレンスには、forced_login_methodという設定があります。

設定できる値は次の2つです。

chatgpt
api

公式リファレンスでは、Codexで使用できる認証方法を特定の方法に制限する設定として説明されています。

ChatGPTログインだけを使いたい場合は、config.tomlへ次の1行を追加します。

forced_login_method = "chatgpt"

Windowsでは通常、設定ファイルは次の場所です。

%USERPROFILE%\.codex\config.toml

macOSやLinuxでは次の場所です。

~/.codex/config.toml

forced_login_methodはトップレベルの設定です。既存のconfig.tomlに[features]や[mcp_servers.xxx]などのテーブルがある場合は、最初のテーブル見出しより前へ置くと位置を判断しやすくなります。

forced_login_method = "chatgpt"

[features]
# 既存設定

TOMLでは、テーブル見出しの後ろに書いたキーがそのテーブルの設定として解釈されます。既存ファイルへ追記するときは、値だけでなく配置場所も確認してください。

設定後はCodexを新しいプロセスで起動し、認証状態を確認します。

codex login status

実行中の利用状況は、Codex CLIで次を入力して確認できます。

/status

以前のCodex CLIの使い方の記事では、AGENTS.md、レビュー、codex execなどを扱いました。今回のforced_login_methodは、リポジトリ内の作業ルールより外側にある、Codexクライアント自体の認証設定です。

この設定で制限できる範囲#

forced_login_method = "chatgpt"を設定すると、Codexで使用できる認証方式をChatGPTへ固定できます。

この設定を入れた場合、Codex自身の認証については次の状態を作れます。

• ChatGPTログインを認証方法として使用します
• API認証をCodexの認証方法として使用できない状態にします
• 認証方法を固定した状態でCodexを運用できます

API課金を避けたいときに、この設定が役立つ理由はここにあります。

Codex CLI自身に「ChatGPT認証を使う」と明示できるため、認証方法の選択肢を事前に狭められます。

ただし、この設定を「PC全体のOpenAI API通信を禁止する機能」として扱うことはできません。また、「月額○円まで」といった金額上限を設定する機能でもありません。

対象はCodexの認証方法です。

APIキーを使う別プログラムまでは止まりません#

今回の設定で特に注意したいのが、Codexから起動した別プログラムです。

たとえばCodexに次のようなコマンドを実行させたとします。

python tools/generate.py

このPythonプログラムがOpenAI SDKを利用し、環境変数OPENAI_API_KEYからAPIキーを読み込む実装になっていれば、そのプログラムはOpenAI APIへリクエストできます。

forced_login_method = "chatgpt"はCodexの認証方法を制限する設定なので、子プロセスが独自にAPIキーを使う処理までは止めません。

Windows PowerShellでは、APIキーの値を表示せず、環境変数が存在するかだけ確認できます。

if (Test-Path Env:OPENAI_API_KEY) { "OPENAI_API_KEY is set" }

APIキーそのものを画面へ表示すると、ターミナル履歴やスクリーンショットへ残る可能性があります。存在確認だけなら、キーの中身を出す必要はありません。

ローカル環境でAPIを使うスクリプトやCLIを併用している場合は、Codexの認証設定と、各プログラムが参照するAPIキーを別々に確認してください。

ここはforced_login_methodの大きな制限点です。Codex側をChatGPT認証へ固定しても、同じPC上にある別のAPI利用経路まで一括で停止することはできません。

AGENTS.mdには作業中の停止ルールを書けます#

AGENTS.mdにも、長時間処理や利用枠に関するルールを書いておくことはできます。

ゆまラボのAGENTS.mdでは、Astroの開発サーバー起動方法、参照する公式ドキュメント、ローカル側で管理しているX投稿の履歴やコマンドなど、リポジトリ固有の運用ルールを記載しています。

同じ考え方で、Codexの利用枠が尽きたときのルールを追加するなら、たとえば次のように書けます。

## Cost guard

- If the current ChatGPT/Codex allowance is exhausted, stop and report it.
- Keep Codex authentication on ChatGPT.
- Do not choose API authentication as a fallback for Codex tasks.
- Before expanding a task into a large repository-wide change or repeated fix/build loop, stop and report the current state.

これはCodexへ渡す作業ルールとして有効です。

ただし、AGENTS.mdはエージェントへの指示です。Codexクライアントの認証方法そのものを技術的に固定する設定はconfig.toml側にあります。

そのため、用途を分けて考えると分かりやすくなります。

• config.toml：Codexの認証方法を制限します
• AGENTS.md：タスク実行中の判断や停止条件を指示します

API認証をCodexで使わせたくない場合は、forced_login_methodを設定したうえで、AGENTS.mdにも「利用枠到達時は停止する」と書いておくと、設定と運用の両面から対策できます。

追加クレジットは別に確認が必要です#

forced_login_method = "chatgpt"を設定しても、ChatGPT側で利用できる追加クレジットの扱いは別です。

OpenAIの案内では、対象となるChatGPTプランでCodexの利用枠に達したあと、追加クレジットを購入して利用を続けられる場合があります。

forced_login_methodはChatGPT認証を固定するための設定です。ChatGPT側で購入済みのクレジットを消費しないようにする金額制限機能としては使えません。

そのため、「OpenAI API側の従量課金を避けたい」という目的と、「追加クレジットを含めて追加料金を一切使いたくない」という目的では、確認する場所が変わります。

後者まで止めたい場合は、ChatGPT側の使用状況とクレジット残高も確認してください。

rollout budgetは金額上限として扱わない方が安全です#

Codexの設定リファレンスには、開発中の機能としてfeatures.rollout_budgetも掲載されています。

現在のリファレンスでは、limit_tokensを設定してrollout budget trackingを有効化できると説明されています。

例としては次のような形です。

[features.rollout_budget]
enabled = true
limit_tokens = 100000
reminder_interval_tokens = 10000
sampling_token_weight = 1.0
prefill_token_weight = 1.0

ただし、公式リファレンスではこの機能を「API料金の上限」や「○円に達したら課金を止める機能」として説明していません。

そのため、rollout_budgetを課金事故を防ぐ唯一の安全装置として使うのは避けた方がよいです。現時点では、長い処理で使うトークン量を追跡するための補助的な機能として見るのが分かりやすいでしょう。

API Platform側には、API利用に対する支出管理や上限設定の仕組みもあります。APIを普段から利用している環境では、Codexの認証設定とAPI Platform側の支出管理をそれぞれ確認しておく方が安全です。

長時間実行の前に確認しておきたいこと#

Codex CLIを長時間動かす場合は、少なくとも次の3点を分けて確認しておくと状況を把握しやすくなります。

1. config.tomlでCodexの認証方法をChatGPTへ固定しているか
2. codex login statusと/statusで認証状態・利用状況を確認できるか
3. OPENAI_API_KEYを使う別スクリプトやCLIが同時に動いていないか

Xで頂いたコメントでは、不安を感じた時点でルーター側の通信を止めたとのことでした。ルーターで遮断すれば通信自体は止められますが、Codex以外の通信にも影響します。

普段の運用では、Codexの認証方法を先に固定し、APIを使う別プロセスがあるかを確認し、利用枠は/statusで追う方が原因を切り分けやすくなります。

今回のコメントから、上限到達後にCodexが自動でAPI認証へ切り替わる仕様だとは判断できませんでした。一方で、Codexの認証方法をChatGPTに限定する設定が公式に用意されていることは確認できました。

Codex CLIをChatGPT認証だけで使いたい場合は、次の設定を確認しておく価値があります。

forced_login_method = "chatgpt"

特に、Codexを長時間自動で回す運用や、複数のAI CLI・API利用スクリプトを同時に動かしている環境では、認証経路を事前に明示しておくと確認箇所を減らせます。

参考#

• OpenAI Codex Configuration Reference
• OpenAI Help: ChatGPTプランでCodexを使う
• OpenAI Help: ChatGPTの個人向けプランでクレジットを使う
• OpenAI Help: ChatGPTとAPI Platformの請求管理
• ゆまラボ：Codex CLIの使い方｜ローカル開発で便利なAGENTS.md・レビュー・exec
• ゆまラボ：CodexのLunaとAstraはどちらが小さな改修向き？Astro実作業で比較

※ 記事内の図は内容を整理するために作成した概念図です。各社の公式資料や実際の製品画面ではありません。