OpenCodexでCodexに他社モデルをつなぐ方法と、導入前の境界
Codexの操作、承認、差分確認は気に入っている。でも、課題によってClaudeやGemini、Grok、ローカルモデルも使い分けたい。OpenCodexは、その間にローカルの変換レイヤーを置くプロジェクトです。
ただし、これはOpenAIが提供する公式のマルチモデル機能ではありません。便利さの裏側に、第三者プロキシ、APIキー、利用規約、ツール権限という判断が残ります。
モデルを変えても、作業の手順は残せる。
AIコーディングの乗り換えで面倒なのは、モデル名を変えることではありません。毎回の承認、リポジトリの読み方、テストの回し方、差分を確認する癖まで変わることです。
OpenCodexは、Codex CLI、App、SDKなどが話すResponses APIを入口にし、上流のプロバイダが話す形式へ翻訳します。公式READMEでは、Claude、Gemini、Grok、DeepSeek、Ollamaなど、OpenAI互換エンドポイントを含む複数の接続先を案内しています。
同じ承認と操作
変換・ルーティング
Ollamaほか
プロバイダとは、実際にモデルへリクエストを送る接続先です。OpenCodexでは、接続先のURL、通信形式、認証方法、モデル一覧をひとまとまりとして登録します。
最短ルートは、npm、ローカル起動、対話セットアップ。
公式READMEが案内する公開パッケージは、Node.js 18以上を前提にしています。Bunランタイムはインストールパッケージに含まれるため、最初から別途Bunを入れる必要はありません。
npm install -g @bitkyc08/opencodex
ocx start
ocx init- 01インストール。ユーザー所有のNode環境で実行します。システム全体へ無理にsudoで入れる必要はありません。
- 02プロキシを起動。
ocx startでローカルサービスを起動し、http://localhost:10100のダッシュボードを開きます。 - 03接続先を追加。ダッシュボードでAPIキー、ベースURL、モデルを登録します。秘密情報は環境変数参照にできます。
- 04Codexへ配線。
ocx initの対話セットアップで、設定を書き込み、Codexとの接続を整えます。
ocx status、ocx doctor、ocx healthで起動状態を確認できます。ocx initはプロキシを自動起動するコマンドではないため、到達不能のままヘッドレス操作を続けないでください。
APIキーは設定ファイルに直書きせず、ルートを名前で固定する。
設定ファイルは通常、~/.opencodex/config.jsonに置かれます。公式ドキュメントでは、APIキーの値に環境変数参照を使えると説明されています。ここでは、Anthropic互換の接続先を例にします。
{
"port": 10100,
"defaultProvider": "anthropic",
"providers": {
"anthropic": {
"adapter": "anthropic",
"baseUrl": "https://api.anthropic.com",
"authMode": "key",
"apiKey": "${ANTHROPIC_API_KEY}",
"defaultModel": "claude-sonnet-4-6"
}
}
}この例の`${ANTHROPIC_API_KEY}`は、記事に秘密鍵を書かないための表記です。自分の環境で変数を設定し、接続先の利用規約と請求先を確認してから実行します。
anthropic/claude-sonnet-4-6
名前空間で接続先を指定。ルーティングの意図が読みやすい形です。
openrouter/openai/...
互換エンドポイントを登録した場合のプロバイダ / モデル表記です。
ollama/llama3
localhostのOpenAI互換サーバーへ向ける構成も取れます。
モデル名だけでなく、どのプロバイダへ送ったかをログと設定で追えるようにすることが重要です。名前解決に任せると、あとから「この成果物はどのモデルと条件で作ったのか」が分からなくなります。
Codex Appに出てくることと、使えることは同じではない。
OpenCodexのCodex Appガイドには、App自体にパッチを当てるのではなく、Codex CLI/TUIと同じ設定・モデルカタログを書くとあります。Appのapp-serverは共有状態を読みますが、一部のデスクトップ版には、表示できる遠隔モデルの許可リストが別にあり、ルーティングされた行が消える場合があります。
まずCLIで検証する
プロキシの起動、APIキー、モデル名、ツール呼び出し、承認が機能するかを小さなリポジトリで確認します。
一覧に出ても権利は別
モデルピッカーの行はカタログが用意された印であり、アカウントやAPIキーがそのモデルを使える保証ではありません。
戻せる手順を先に作る
元のCodex設定を保存し、プロキシ停止時にネイティブ構成へ戻せることを確認します。
便利さを急いでAppに広げるより、CLIで1つのタスクを完了し、同じタスクをネイティブCodexでも実行して比較するほうが原因を切り分けやすい。差が出たとき、それがモデルか、変換か、Appの表示制限かを追えます。
「つながる」より先に、どこで止めるかを決める。
OpenCodexはMITライセンスの独立プロジェクトで、OpenAIやAnthropicなどの提供元が承認した公式製品ではありません。README自身も、第三者プロキシ経由のAPI通信によって、プロバイダによってはアカウント制限や停止の対象になり得るため、各社の規約を確認するよう注意しています。
鍵を増やさない
環境変数を使い、設定ファイル、シェル履歴、ログ、スクリーンショットにAPIキーが出ていないか確認します。
loopbackを保つ
初期値の127.0.0.1から外へ公開する場合、bearer tokenが必要です。LANやインターネットへ出すなら脅威モデルを作ります。
権限を増やさない
プロキシを通したから安全になるわけではありません。シェル、ファイル削除、外部送信、実行権限はCodex側の承認とサンドボックスで制限します。
契約を確認する
サブスクリプション経由のAPIやOAuthを第三者プロキシへ流せるかはサービスごとに異なります。READMEの免責を読み、提供元の規約も確認します。
最初の安全な一歩は、ローカルで読み取り中心のタスクを1件だけ実行することです。ファイルを書き換える前に、接続先、モデル名、送信内容、課金先、権限の境界を自分で説明できる状態にします。