Codex接入第三方模型失败的根本原因是协议不兼容：新版强制用Responses API（/v1/responses），而DeepSeek、千问等只支持Chat Completions API（/v1/chat/completions），需通过CC Switch等桥接层转换协议。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
想让 Codex 连上 DeepSeek、千问、Kimi 或本地部署的 Qwen 模型，却卡在 404、400 或模型列表空白？根本原因不是密钥错了、地址填错了，而是 Codex 0.122.0 和 0.80.0 使用了两套互不兼容的通信“语言”，直接对话必然失败。
协议本质差异：Codex 在说什么，第三方模型听什么
0.122.0 及以上版本强制使用 OpenAI 新推出的 Responses API（/v1/responses），它把请求体结构、流式事件命名（如 data: response、data: done）、响应字段语义都做了重构；而 DeepSeek、SiliconFlow、阿里云百炼（非 qwen3.7-max 等特例）、本地 Ollama/Qwen 服务等，99% 都只实现标准的 Chat Completions API（/v1/chat/completions）。
这就像你用德语问路，对方只会法语——语法不同、关键词不匹配、连标点分隔逻辑都对不上，根本无法解析请求体，自然返回 404 或空响应。
版本与 wire_api 的绑定关系
0.122.0 版本中，wire_api = "chat" 这个配置会被直接忽略或报错，系统强制走 responses 协议；而 0.80.0 版本中，wire_api = "chat" 是唯一合法且生效的取值，写成 responses 会启动失败。
这不是可选项，是硬性限制。装错版本，后续所有配置都白写。
如何验证当前 Codex 实际走的是哪个协议
方法一：查看日志输出
执行 codex run --debug 后观察终端第一行请求 URL。若看到 /v1/responses 或 /responses，说明走的是 Responses 协议；若看到 /v1/chat/completions，则是 Chat 协议。
方法二：抓包验证
用 mitmproxy 或 Charles 监听 localhost:15721（CC Switch）或 Codex 直连目标地址的出站请求，看实际发出的 path 和 request body 字段是否含 choices、message、delta 等 Chat 特征字段，或含 response_id、response_type、response_state 等 Responses 特征字段。
通过 Codex CLI 生成图片，支持尺寸控制和批量模式。依赖：codex (npm)。代理默认启用。用 generate.sh 生成单张，batch_generate.sh 批量生成游戏 UI 素材，gen_size.sh 指定尺寸。所有输出保存至 ~/.codex/generated_images/。
注意：Codex CLI 不会主动打印协议类型，必须靠外部观测确认。
正确接入第三方模型的路径选择
第一步：确认你要接入的服务是否原生支持 Responses API
目前仅 qwen3.7-max、qwen3.6-plus（阿里云百炼 Responses 专属版）等极少数模型明确支持。其余全部默认只支持 Chat Completions。
第二步：根据服务能力反向决定 Codex 版本
① 若服务只支持 Chat → 必须降级到 Codex 0.80.0：
npm install -g @openai/codex@0.80.0
② 若服务已适配 Responses → 可保留 0.122.0，但需确保 base_url 指向 /v1/responses 端点，且 wire_api = "responses"（此为默认值，无需显式配置）。
第三步：环境变量必须通过 shell 注入，不可写入 config.toml
OPENAI_API_KEY 或 CUSTOM_API_KEY 必须设为系统环境变量，否则 0.80.0 与 0.122.0 均会静默忽略配置文件中的 key 字段，导致认证失败。
