Codex 連携

Codex は cc-router の POST /v1/responses 入口を通じて、cc-router に設定したすべてのモデルを呼び出します。上流が Anthropic プロトコルでも OpenAI プロトコルでも cc-router が自動で変換し、仮想モデルに従って振り分けます。

Codex CLI と Codex Desktop は同じ ~/.codex/ 設定を共有するので、一度編集すれば両方に反映されます。以下の 3 ステップで 2 つのファイルを手動で編集してください。

cc-router アプリの セットアップガイド → Codex タブにも同じ 3 ステップのチュートリアルがあり、設定スニペットは現在のポートとトークンに合わせて生成済みです。そこからそのままコピーするのが最も手軽です。

代替手段：すでに cc-switch で複数の Codex プロバイダを管理している場合は、Codex 連携（cc-switch）の経路も利用できます。

前提条件

クイックスタートに沿って cc-router をインストールし、最低 1 つの仮想モデルをバインド済み
Codex CLI または Codex Desktop のいずれかをインストール済み
Claude Desktop 連携とは異なり、Codex 経路は HTTP ポートのみ（既定は 23456）を使用します。HTTPS も CA 証明書も不要です。

ステップ 1：config.toml を編集

以下の内容を ~/.codex/config.toml に追加します（ファイルがなければ新規作成）。cc-router という名前のカスタム provider（OpenAI Responses プロトコルを使用）と、同名の profile を登録します：

# cc-router 推奨設定 — cc-router セットアップガイドで生成
# 使い方: codex -p cc-router "質問内容"
# 編集後は保存するだけで OK。codex は次回起動時にこのファイルを読み込みます

[model_providers.cc-router]
name = "cc-router"
base_url = "http://127.0.0.1:23456/v1"
wire_api = "responses"
env_key = "OPENAI_API_KEY"

[profiles.cc-router]
model_provider = "cc-router"
model = "model-sonnet"

ファイルに既存の設定がある場合は、この 2 つのセクションを末尾に追記するだけで OK です。以前に [model_providers.cc-router] や [profiles.cc-router] を追加していた場合は、先に古い同名セクションを削除してください。TOML ではテーブルの重複が許されません。
base_url は必ず /v1 で終わる必要があります。Codex はその後ろに /responses を付加します。ポートは cc-router 設定ページに表示される実際のポートを使ってください。

ステップ 2：auth.json を編集

~/.codex/auth.json の内容をすべて以下に置き換えます（ファイルがなければ新規作成）：

{
  "OPENAI_API_KEY": "<cc-router トークン>"
}

OPENAI_API_KEY は cc-router のトークンで、Claude Code が使うものと同じです。cc-router の設定ページで確認できます。config.toml の env_key = "OPENAI_API_KEY" により、Codex はこのフィールドで認証します。cc-router の認証が無効なら任意の値で構いません。
先にバックアップ：以前に ChatGPT アカウントで Codex にログインしていた場合、auth.json には公式のログイン認証情報が入っています。置き換える前に元のファイルをコピーしてバックアップしてください。公式ログインに戻すときは、バックアップを元の名前に戻せば OK です。
cc-router の設定でトークンを再生成した場合は、このファイルも更新してください。

ステップ 3：Codex を起動

ターミナルで -p cc-router を付けて profile を指定し、Codex CLI を起動します：

codex -p cc-router "質問内容"

Codex Desktop も同じ設定を読み込みます。編集後に Codex Desktop を一度再起動し、モデルセレクタで cc-router profile を選んでください。

別の仮想モデルを使う

config.toml の [profiles.cc-router] にある model が、どの仮想モデルを使うかを決めます。以下のいずれかに変更して保存すると、Codex の次回起動時に反映されます：

`model` の値	適した用途
`model-fable`	最も難しいタスク
`model-opus`	計画、長コンテキスト推論
`model-sonnet`	主力のコーディング（既定）
`model-haiku`	ツール呼び出し、軽量タスク

ここには cc-router の仮想モデル名をそのまま書きます。gpt-5.5、gpt-5.4 などのエイリアスも使えます。対応関係はエンドポイント概要 → 仮想モデルとエイリアスを参照してください。

LAN 共有

Codex と cc-router が別のマシンにある場合は、まず cc-router の設定でリッスンアドレスを LAN（0.0.0.0）に変更し、base_url の 127.0.0.1 を cc-router が動いているマシンの LAN IP に置き換えます。末尾の /v1 は必須です：

base_url = "http://192.168.1.50:23456/v1"

検証

Codex で一度会話してから cc-router の リクエストログ を開きます。クライアント 列に Codex CLI または Codex Desktop、仮想モデル 列に対応するスロット、実モデル 列に最終的にルーティングされた上流モデルが表示されれば成功です。

リアルタイムルーティング ページの「クライアント接続」表でも、Codex が接続済みとして表示されます。

トラブルシューティング

404 Not Found —— base_url の末尾に /v1 がありません。cc-router の Responses 入口は /v1/responses です。
401 Unauthorized —— auth.json のトークンが cc-router の現在のトークンと一致していません（再生成した場合など）。ステップ 2 に従ってもう一度入力してください。
リクエストが cc-router を経由しない —— CLI の起動時に -p cc-router を付け忘れたか、設定変更後に Codex Desktop を再起動していません。
モデルが違う、または model_not_found —— model フィールドの綴りが間違っています。綴りを誤った名前は fallback 仮想モデルに回されるので、上の表の仮想モデル名を使ってください。
接続が拒否される —— cc-router のプロキシが動いていないか、base_url のポートが実際のポートと一致していません。

セキュリティに関する注意

auth.json のトークンはすべての上流サブスクリプションを呼び出せる認証情報で、しかも平文で保存されます。漏洩させないこと、リポジトリにコミットしないこと。
cc-router のポートは信頼できる LAN 内でのみ公開してください。公開ネットワークへの露出はリスクを自己評価し、リバースプロキシと認証層で強化してください。