Codex CLI Model Bridge

Manage subscription-backed or local proxy models in Codex without treating Codex like WorkBuddy. Codex uses a Responses API Provider plus a model catalog; WorkBuddy uses independent JSON entries. Share CLIProxyAPI infrastructure and verified Provider facts, but keep each application's writer and state separate.

Codex selects one model_provider for a task. Model catalog entries do not carry per-model Provider routing. Preserve the Provider identity that owns the majority of indexed task history (normally openai). For normal Desktop use, the supported bridge design keeps model_provider = "openai", keeps ChatGPT subscription auth intact, and points the built-in Provider's openai_base_url at an owner-only loopback header-rewriting proxy. CLIProxyAPI then routes native GPT subscription models and verified third-party models behind one catalog without changing the task Provider identity. Keep the isolated $CODEX_HOME/cli-proxy.config.toml profile as the default path on Windows and as a fallback everywhere else.

This is transparent single-Provider routing, not per-model Provider routing. Never set the Desktop default to cli_proxy or vendor ZAI when most history belongs to openai.

When the user wants GLM-5.3 from a Coding Plan key, read glm-coding-plan.md. If Desktop already uses Codex Router on port 4202, add zai-coding there and keep the OpenAI Provider identity. Do not run npx @z_ai/coding-helper.

On Windows, start with the isolated profile. Read windows.md. Do not require Homebrew, LaunchAgents, or Codex Router.

Resolve the Skill directory

Resolve this loaded Skill's directory as <skill-dir>. Resolve <python> as the first available of python3, py -3, and python. Use the deterministic entry point:

<python> <skill-dir>/scripts/bridge.py