Codex で GLM Coding Plan を使う｜config.toml の書き方と、wire

この記事の要点

設定に要るファイル：モデル情報を宣言する JSON と、接続先とキーを書く TOML の 2 ファイル。公式の手順はどちらもホームの .codex フォルダに置き、端末から自動で設定する経路も別にある。
古い手順が止まる理由：Codex が話すプロトコルは Responses だけに絞られ、wire_api に chat を書いた設定は起動の読み込み段階で拒否される。
「OpenAI 互換」の読み方：Z.ai は接続先をプロトコル別に 3 つに分けている。互換の表示だけでは向ける先は決まらず、接続先はツールが話すプロトコルで決まる。

この結果が言える範囲：2026年9月15日時点の公式ドキュメントと Codex のソースの記述をまとめたもの。

Codex に GLM Coding Plan を挿す設定
wire_api に chat を書いた手順は、いま起動時に止まる
キーもモデル名も正しいのに噛み合わない：接続先はプロトコル別に 3 つに分かれている
Claude Code に挿す場合との違い
API キーをどこに置くか
glm-5.2 と書いた設定はどこまで分かるか、推論量の値はどこまで載っているか
まとめ
よくある質問
参考資料

Codex に GLM Coding Plan を挿す設定

Z.ai の Codex 向けページは、Codex を OpenAI のコーディングエージェントと説明し、端末で動く CLI とデスクトップアプリの 2 つの形態があるとしている。そのページは CLI の導入に続けて、設定ファイルを書く手順を示している。Codex そのものを触るのが初めてなら、対応モデルや機能の前提はClaude Code と OpenAI Codex の比較記事で扱っている。

同じページは、Codex が OpenAI Responses プロトコル専用のエンドポイント https://api.z.ai/api/v1 を必要とすると明記している。Codex が Responses だけを話すという 1 点から、接続先に Responses 専用のエンドポイントを書くことと、wire_api に responses 以外を書けないことの両方が出る。設定ファイルの中身も、古い手順が起動時に止まる理由も、この 1 点にさかのぼる。

前提と導入のコマンド

Z.ai の Codex 向けページが案内する導入は npm 経由で、Node.js 18 以上を前提としている。npm install -g @openai/codex を端末で実行し、確認は codex --version で、バージョン番号が表示されれば成功とされている。

macOS については、Node.js を nvm 経由で入れることが推奨され、パッケージを直接入れる方法は後から権限の問題を招きうるとして推奨されていない、と書かれている。

API キーの取得場所はプランで分かれる

キーを作る画面はプランで分かれる。個人プランは Individual Coding Plan > Plan Overview、チームプランは Team Coding Plan > My Plan。チームプランのキーは他の Z.AI の API キーと交換して使えず、チームプランの割り当てを使うにはチームプランのキーを使う必要がある、と案内されている。取得先を間違えると、設定ファイルの書式が正しくても割り当てが噛み合わない。

Z.ai の Codex 向けページは、API キーを安全に保ち、他人と共有せず、コードに直接ハードコードしないよう書いている。一方で同じページが示す設定手順は、キーを設定ファイルへ直接書かせる。設定ファイルはコードとは別の場所だが、キーの文字列がそのまま残る点は共通する。置き場所の選択肢は「API キーをどこに置くか」で扱う。

先に models.json でモデル情報を宣言する

config.toml より先に ~/.codex/models.json を作り、GLM のモデル情報を Codex へ宣言する、と公式は書いている。ファイルもフォルダも無ければ先に作る。公式が載せるカタログは、最上位の models 配列にモデルの定義を 1 つ置く形で、次の内容をそのまま写す。

{
    "models": [
        {
            "slug": "glm-5.3",
            "display_name": "glm-5.3",
            "description": "Z.ai's latest flagship model",
            "default_reasoning_level": "max",
            "supported_reasoning_levels": [
                {
                    "effort": "low",
                    "description": "Light reasoning"
                },
                {
                    "effort": "high",
                    "description": "Enhanced reasoning"
                },
                {
                    "effort": "max",
                    "description": "Deep reasoning"
                }
            ],
            "shell_type": "shell_command",
            "visibility": "list",
            "supported_in_api": true,
            "priority": 0,
            "base_instructions": "",
            "supports_reasoning_summaries": true,
            "default_reasoning_summary": "none",
            "support_verbosity": false,
            "apply_patch_tool_type": "freeform",
            "truncation_policy": {
                "mode": "bytes",
                "limit": 10000
            },
            "context_window": 1048576,
            "max_context_window": 1048576,
            "effective_context_window_percent": 95,
            "supports_parallel_tool_calls": true,
            "experimental_supported_tools": [],
            "input_modalities": [
                "text"
            ]
        }
    ]
}

モデルを差し替えるとき、名前にあたる slug と display_name、推論量の宣言にあたる default_reasoning_level と supported_reasoning_levels、コンテキスト長の context_window と max_context_window が書き換えの対象に入る。カタログはモデルごとの情報を宣言するもので、書き換える項目がこの 6 つに限られるわけではない。

出所は Z.AI 開発者ドキュメントの Codex 向けページ（2026年9月15日確認）。

models.json のカタログを読み込ませる項目について、Codex の設定リファレンスは model_catalog_json を「起動時に読み込まれる JSON のモデルカタログへの任意のパス」と説明している。必須ではない項目で、外部のモデル情報を起動時に読ませる入口が用意されており、Z.ai の手順はその入口を使って GLM のカタログを渡している。

config.toml に接続先とキーを書く

設定ファイルの場所は、macOS と Linux が ~/.codex/config.toml、Windows はホームディレクトリ直下の .codex フォルダに置く config.toml。無ければ作る。カタログの models.json も同じ .codex フォルダに置く。公式が示す中身は次のとおり。

model_provider = "ZAI"
model = "glm-5.3"
model_reasoning_effort = "max"
model_catalog_json = "~/.codex/models.json"

[model_providers.ZAI]
name = "ZAI"
base_url = "https://api.z.ai/api/v1"
experimental_bearer_token = "<Your API Key>"
wire_api = "responses"

公式は設定例の直後に、wire_api を responses にしなければならないと注記している。model については、glm-5.3 のほか models.json に宣言した別のモデルへ必要に応じて切り替えられる、と書かれている。切り替えの前提はカタログへの宣言で、カタログに無い名前を model に書く形は手順の外に出る。model に glm-5.2 のような古い名前を書いたときに公式がどこまで書いているかは「glm-5.2 と書いた設定はどこまで分かるか」で扱う。

2 つのファイルを書き終えたら Codex を起動し直す。公式が案内しているのは、Codex のウィンドウをすべて閉じ、新しい端末を開いて codex を実行する手順まで。反映されないときに公式が挙げる確認は「よくある質問」で扱う。

手で書かずに設定する経路

手で 2 つのファイルを書く経路とは別に、端末で npx @z_ai/coding-helper を実行し、画面の案内に従う経路が用意されている。ツールの導入とプランの設定をまとめて行い、GLM Coding Plan を Codex へ読み込ませるヘルパーとして案内されている。

wire_api に chat を書いた手順は、いま起動時に止まる

Codex の設定リファレンスは、model_providers の wire_api について「responses が唯一のサポート値であり、省略したときの既定値でもある」と記している。選べる値が複数あってその中から選ぶ項目ではなく、値がひとつしか残っていない項目だという説明である。

Codex のソースでも同じで、プロトコルの値として定義されているのは Responses だけ。それが既定値として指定されている。

pub enum WireApi {
    /// The Responses API exposed by OpenAI at `/v1/responses`.
    #[default]
    Responses,
}

設定の読み込みで chat という値を見つけたときの扱いも、同じソースに書かれている。値の解釈に失敗したという形で誤りを返す。

"chat" => Err(serde::de::Error::custom(CHAT_WIRE_API_REMOVED_ERROR))

返る文言は次のとおり。修正方法と、廃止を告知した議論へのリンクが、同じ文言の中に入っている。

`wire_api = "chat"` is no longer supported.
How to fix: set `wire_api = "responses"` in your provider config.
More info: https://github.com/openai/codex/discussions/7782

止まる場所は接続の途中ではなく、設定を読み込む段階。接続先の指定やキーが正しいかどうかとは別のところで弾かれるため、エンドポイントを書き換えても、キーを作り直しても解消しない。

chat/completions 対応の廃止は 2025年12月9日に告知され、告知の本文は完全な削除の時期を 2026年2月上旬としていた。wire_api に chat を書く手順は、この削除より前の時期に書かれたものにあたる。

既定値の記述そのものが割れていた時期もある。2026年3月5日には、公開のリファレンスが wire_api の既定値を chat と書き、生成されたスキーマは responses としている食い違いが報告された。報告は閉じられ、現在のリファレンスは responses を唯一のサポート値と記している。省略したときの挙動を古いリファレンスの記述で覚えていると、現在の記述と逆の前提を持つ。

キーもモデル名も正しいのに噛み合わない：接続先はプロトコル別に 3 つに分かれている

Z.AI 開発者ドキュメントは接続先をプロトコル別に 3 つ挙げている。Codex が必要とする Responses の口が https://api.z.ai/api/v1 で、Anthropic Messages と OpenAI Chat Completions にはそれぞれ別の基底 URL が割り当てられている。

プロトコル	エンドポイント
Anthropic Messages	`https://api.z.ai/api/anthropic`
OpenAI Chat Completions	`https://api.z.ai/api/coding/paas/v4`
OpenAI Responses	`https://api.z.ai/api/v1`

出所は Z.AI 開発者ドキュメントの Tool Integration のページが挙げるプロトコルと Base URL の対応。Responses の口を Codex が必要とすることは同ドキュメントの Codex 向けページにも明記されている（いずれも 2026年9月15日確認）。

Chat Completions と Responses はどちらも OpenAI の名前が付くが、Z.ai は別の接続先として扱っている。Codex が必要とするのは Responses のエンドポイントで、Chat Completions のエンドポイントは、そのプロトコルを話す別のツールのための接続先である。ツールの説明にある「OpenAI 互換」の表示は、この 2 つのどちらを話すかまでは示さない。

ツールの説明に「OpenAI 互換に対応」と書かれていても、どのエンドポイントへ向ければよいかは決まらない。決めるのはツールが実際に話すプロトコルで、複数のプロトコルを設定で選べるツールなら、選んだほうに合わせて基底 URL が決まる。Codex のように話すプロトコルが 1 つなら、向ける先も 1 つに決まる。互換の表示だけを見て手近な URL を書くと、キーもモデル名も正しいのに接続先が噛み合わない構成ができる。

GLM Coding Plan は公式に対応が示されたツールと製品の内での利用に限られ、その外のツールや用途に契約の枠を使うことは認められていない、と Z.AI 開発者ドキュメントの Tool Integration のページは書いている。同じページが挙げる対応ツールには Codex も入っている。設定手順そのものは Z.ai が Codex 向けに用意したページにあり、本記事がたどっているのはその手順にあたる。

Tool Integration のページは、使っているツールに応じて正しいエンドポイントを選ぶよう求め、エンドポイントの設定を誤ると GLM Coding Plan の枠を使えないとも書いている。接続先を取り違えたときに起きることとして、構成が噛み合わないほかに、契約した枠を使えないという形も公式に書かれている。

Claude Code に挿す場合との違い

同じ GLM を別のハーネスへ挿すと、書く場所も書き方も変わる。Claude Code 向けページの手動設定は、~/.claude/settings.json の env に ANTHROPIC_AUTH_TOKEN と ANTHROPIC_BASE_URL を書く形で、基底 URL には https://api.z.ai/api/anthropic を置く。

モデルの指定も形が違う。手動設定の例は ANTHROPIC_DEFAULT_HAIKU_MODEL に glm-5.3-flash[1m]、ANTHROPIC_DEFAULT_SONNET_MODEL と ANTHROPIC_DEFAULT_OPUS_MODEL に glm-5.3[1m] を置き、CLAUDE_CODE_AUTO_COMPACT_WINDOW に 1000000、API_TIMEOUT_MS に 3000000 を置く形である。手動設定の例では、モデル名に [1m] の接尾辞が付いた形が使われている。

設定する内容	Codex（config.toml）	Claude Code（settings.json の env）
書く場所	`~/.codex/config.toml` と `~/.codex/models.json`	`~/.claude/settings.json`
接続先	`base_url`	`ANTHROPIC_BASE_URL`
キー	`experimental_bearer_token`（Z.ai の手順が書く項目。リファレンスは `env_key` を挙げる）	`ANTHROPIC_AUTH_TOKEN`
モデルの指定	`model` にモデル名を書く	Haiku・Sonnet・Opus の 3 つの環境変数へ割り当てる
コンテキスト長に関わる項目	`models.json` の `context_window` と `max_context_window`	`CLAUDE_CODE_AUTO_COMPACT_WINDOW`（設定例の値は `1000000`）

Codex の列の出所は Z.AI 開発者ドキュメントの Codex 向けページと Codex 設定リファレンス、Claude Code の列の出所は Z.AI 開発者ドキュメントの Claude Code 向けページ（いずれも 2026年9月15日確認）。

Claude Code 向けページは、環境変数と GLM モデルの既定の対応として ANTHROPIC_DEFAULT_OPUS_MODEL・ANTHROPIC_DEFAULT_SONNET_MODEL・ANTHROPIC_DEFAULT_HAIKU_MODEL の 3 つとも GLM-5.3-Flash を挙げている。同じページの手動設定の例では、Sonnet と Opus に glm-5.3[1m] が置かれている。既定の対応を示す記述と、例が書き込む値という別のことを述べている読み方も成り立つため、2 か所の関係は本記事では決めない。

同じページは、最新の GLM-5.3 を使う場合の手順として使用モデルの切り替えを案内している。この案内も既定の読み方に関わるが、2 か所の記述の関係を決める材料としては扱わない。

キーの取得場所の案内も、2 つのページで揃っていない。Claude Code 向けページは Z.AI Open Platform に登録またはログインし、API キー管理ページでキーを作る形を示す。Codex 向けページはプラン別の画面を指定している。片方のページを読んで作ったキーを、もう片方の手順にそのまま流用する前に、案内の違いが残る。

どちらのハーネスへ挿すか、そもそも乗り換えるかを料金やスコアで判断する話は、GLM-5.3はClaudeの代わりに使えるかの記事で扱っている。本記事が扱うのは接続の形だけで、損得の比較は含まない。

API キーをどこに置くか

Z.ai の Codex 向け手順は、キーを config.toml の experimental_bearer_token に直接書く形を採る。Codex の設定リファレンスは experimental_bearer_token を「プロバイダへ直接渡すベアラートークン（非推奨、env_key を使うこと）」と説明している。手順書が選んでいるのは、リファレンスが非推奨と記した項目である。

リファレンスが代わりに挙げる項目が env_key で、「プロバイダの API キーを供給する環境変数」と説明されている。キーの文字列は設定ファイルに残らず、環境変数の名前だけが残る。この形にするなら、公式の設定例の experimental_bearer_token の行を env_key の行に替え、値にはキーそのものではなく環境変数の名前を書く。Z.ai の手順が載せているのは experimental_bearer_token を使う例のほうで、env_key を使う例は示されていない。

3 つ目の置き方が auth のテーブル。Codex がトークンを必要としたときに実行するコマンドを指定する形で、コマンドは標準出力へトークンを出す必要がある。更新間隔の既定は 300000 ミリ秒、コマンドの実行時間の上限の既定は 5000 ミリ秒。auth のテーブルは env_key や experimental_bearer_token と併用しないよう書かれている。

リファレンスがカスタムプロバイダの項目として並べる置き場所は 3 つある。設定ファイルへ直接書く項目、環境変数から読む項目、コマンドの標準出力から受け取るテーブル。そして Z.ai の Codex 向け手順が選んでいるのは、Codex のリファレンスが非推奨と記したものにあたる。同じ Z.ai のページはキーを他人と共有せずコードに直接ハードコードしないよう書いている。

自動で設定する経路のうち、Claude Code 向けページが載せるコマンドは取得元と実行するファイルが読み取れる。Codex 向けページが案内する npx のヘルパーとは別のコマンドで、外部の配信元からスクリプトを取得してその場で実行する。

curl -O "https://cdn.bigmodel.cn/install/claude_code_zai_env.sh" && bash ./claude_code_zai_env.sh

コーディングエージェントへ渡す権限と、実行を隔離する範囲の話は、AIコーディングエージェントのサンドボックスを検証した記事で境界を扱っている。キーの置き場所を選ぶ判断と、エージェントに何を実行させるかの判断は、同じ設定ファイルの上で隣り合う。

glm-5.2 と書いた設定はどこまで分かるか、推論量の値はどこまで載っているか

GLM Coding Plan が対象とするモデルは GLM-5.3 と GLM-5.3-Flash。加えて、GLM-5.2 と GLM-5.1 を指定したリクエストは自動的に GLM-5.3 へ、GLM-4.7 を指定したリクエストは GLM-5.3-Flash へ振り替えられると書かれている。この振り替えが書かれているのはリクエストのモデル指定についてで、Codex の config.toml の model に古い名前を書いたときにこの経路へ乗るかどうかは、models.json への宣言という前提も挟まるため本記事では確かめていない。

推論量の指定は、資料によって載っている値の数が違う。Codex の設定リファレンスは model_reasoning_effort の値として minimal・low・medium・high・xhigh を挙げ、Responses API のみで有効、xhigh はモデル依存と注記している。

Z.ai の設定例は model_reasoning_effort に max を置き、models.json のカタログも推論量として low・high・max を宣言している。Codex のリファレンスが列挙する値に max は含まれないが、Codex の実装は推論量の値として Max を持ち、文字列の max をその値として受け取る。Codex の実装が持つ既定値は medium。リファレンスの一覧は実装より狭く、none・ultra・persistent も同じように載っていない。さらに model_reasoning_effort については、列挙されていない非空の文字列も Custom として受け取り、読み込みで誤りになるのは空文字のときだけ。ただしこれは設定を読み込む層の話で、Custom として渡った値をモデルがどう扱うかはリファレンスにもソースにも書かれていない。

GLM のような定額の契約ではなく、手元のマシンでモデルを動かす選択肢もある。エージェントをローカルのモデルへ繋ぐ設定はOpenCode と Ollama を繋ぐ記事で扱っており、その土台となる推論エンジンの選び方は姉妹サイトのローカルLLM推論エンジン比較にある。

まとめ

接続先を決めるのは互換の表示ではなく、ツールが話すプロトコル。Z.ai は接続先をプロトコル別に 3 つへ分けており、Codex が必要とするのは Responses プロトコル専用のエンドポイントだと Z.ai の Codex 向けページが明記している。

Codex の設定リファレンスは wire_api のサポート値を responses だけとしている。chat を書いた設定は読み込みの段階で誤りとして返るため、wire_api に chat を書いた古い手順をそのまま写すと起動しない。止まる原因は接続先やキーではない。

キーの置き場所は、設定ファイルへ直接書く項目、環境変数から読む項目、コマンドの標準出力から受け取るテーブルの 3 つ。Z.ai の Codex 向け手順が選んでいるのは、Codex のリファレンスが非推奨と記した項目である。どれを使うかは設定を書く時点の選択で決まる。

Codex を使い続ける場合の派生として、手順や指示の書き方を扱うCodex Skills の記事がある。

よくある質問

設定を書き換えても反映されないときは何を確認するか

公式が挙げる確認は 5 つ。Codex のウィンドウをすべて閉じて新しい端末で起動し直すこと、~/.codex/models.json が存在し JSON として妥当なこと、~/.codex/config.toml の model_catalog_json のパスが正しいこと、experimental_bearer_token を実際の API キーに置き換えてあること、そして設定ファイルの TOML の書式が正しいこと。

エラーコード 1214 の Incorrect role information で止まるのは何が起きていたのか

GLM-4.7 を wire_api の chat 指定で https://api.z.ai/api/coding/paas/v4 へ向けた構成について、利用者の報告がある。Codex が developer という役割で messages を送る一方、受け取るエンドポイントが system・user・assistant しか受け付けず、エラーコード 1214 の Incorrect role information で止まったという内容で、報告は 2026年1月21日に出され、その翌日に対応予定なしとして閉じられた。chat の指定そのものが現在の Codex では受け付けられないため、この構成自体を組めない。