配置 Codex CLI 使用 ghc-api

1. 安装 Codex CLI

Shell

npm install -g @openai/codex
codex --version

2. 修改 ~/.codex/config.toml

TOML

model = "YOUR_RESPONSES_MODEL_ID"
model_provider = "ghc-api"
model_reasoning_effort = "high"

[model_providers.ghc-api]
name = "ghc-api"
base_url = "http://127.0.0.1:8313/v1"
env_key = "GHC_API_TOKEN"
wire_api = "responses"

Shell

# 未启用 ghc-api 用户鉴权时可使用占位值
export GHC_API_TOKEN=1
codex

启用鉴权后，将环境变量替换为已批准的用户 Token。Codex 的 base_url 应包含 /v1。

3. 模型与推理强度

先从 /v1/models/full/ 找到 supported_endpoints 包含 /responses 的模型。再检查 capabilities.supports.reasoning_effort，只填写模型明确支持的值。

字段	作用
`model`	发送给 ghc-api 的模型 ID，可使用 config.yaml 中定义的精确别名。
`wire_api`	Codex 使用的协议；这里选择 `responses`。
`model_reasoning_effort`	常见值有 low、medium、high、xhigh，但以模型实时元数据为准。
`env_key`	从环境变量读取 API Token，避免把凭据写进配置文件。

不要假设所有 GPT 模型都支持所有 effort。

ghc-api 会根据上游模型能力过滤或处理参数。客户端配置与模型元数据保持一致，最容易获得稳定行为。

4. 验证与排错

用 curl 确认模型支持 /responses。
启动 Codex 后在 ghc-api Dashboard 确认请求进入 /v1/responses。
401 检查 GHC_API_TOKEN；404 检查 base_url；400 检查模型 ID、reasoning effort 和工具参数。
流式中断时检查反向代理是否关闭 buffering，并有足够长的 read timeout。

延伸阅读：Codex configuration reference ↗

下一步

先查看当前账户真实可用的模型和端点，再把模型 ID 填入客户端配置。

查看模型与参数 →