先确认协议，再动手
Codex CLI 官方配置参考写明：model_providers.<id>.wire_api 仅支持 "responses"，且省略时默认就是它（2026-10-07 核对 developers.openai.com/codex/config-reference）。这意味着只提供 OpenAI Chat Completions（/v1/chat/completions）的网关或中转站，无法接入当前版本的 Codex CLI。
也不存在把 chat 协议“伪装成” Responses 的官方开关——不要用改路径、改请求头之类的假替代方案硬凑，那只会得到运行中途才暴露的隐性失败。服务商若只有 chat 协议，正确做法是给这类端点换用支持 chat 的客户端（见我们的 Cline/Cherry Studio 协议匹配指南），而不是魔改 Codex。
动手前向服务商确认两件事：是否提供 Responses 端点（路径以其文档为准），以及你要用的模型在该端点上可用。2026-10-07 核验的两家中转站里，端点类型是按“分组×模型”声明的（例如 PackyAPI 的 kimi-k3 仅开放 openai-response），不能想当然。
config.toml 最小可用配置
配置文件在 CODEX_HOME（默认 ~/.codex/config.toml）。内置供应商 ID（openai、ollama、lmstudio、amazon-bedrock）是保留名，自定义供应商必须换名。顶层用 model + model_provider 选中供应商；需要附加请求头或查询参数时，官方提供 http_headers / env_http_headers / query_params 字段（官方 Azure 示例即用 query_params 传 api-version）。
# ~/.codex/config.toml（CODEX_HOME 默认 ~/.codex）
model = "MODEL_ID" # 服务商 Responses 端点实际提供的模型 ID
model_provider = "myrelay" # 自定义 ID；内置保留名不可覆盖：
# openai / ollama / lmstudio / amazon-bedrock
[model_providers.myrelay]
name = "My Relay (Responses)"
base_url = "https://api.example.com/v1" # 以服务商文档为准
env_key = "MYRELAY_API_KEY" # 密钥从环境变量读，不写进本文件
wire_api = "responses" # 官方唯一支持值（省略时默认同值）注入密钥并启动
env_key 的值是“环境变量的名字”，不是密钥本身。把密钥写进 config.toml 明文意味着它会被同步、备份、截图连带泄露。
# 密钥只进环境变量（shell 配置或系统密钥管理），不进配置文件明文、不进前端 JS
export MYRELAY_API_KEY="sk-..." # 占位示例
codex # 启动后先发一条简单消息验证验收条件
三条全过才算接通：(1) codex 启动后，会话内可见所选 model 与 provider；(2) 发送一条简单消息能收到完整回复；(3) 关掉终端重开再试一次仍可用——证明密钥来源稳定，不是恰好继承自当前 shell。
常见报错与排查
404 / unknown endpoint：先按服务商官方文档原样核对 base_url 拼写（是否带 /v1、有无其他前缀以官方来源为准，不要按通用惯例猜测），再确认服务商是否真的提供 Responses 端点。401 / invalid key：env_key 拼写错、变量没导出、或密钥属于别的分组。报错提到保留 ID：换掉与内置同名的供应商 ID。请求似乎发到了 chat/completions：配错了供应商，或服务商只支持 chat 协议——这属于协议不匹配，换客户端，别硬改。
排查顺序固定为：协议（有没有 Responses 端点）→ 路径（base_url 拼写）→ 密钥（env_key 与变量名）→ 模型 ID（是否属于该分组）。一次只改一个变量。