Codex 挂上自定义 Provider 后，聊天正常、代码正常，唯独生图一点反应都没有——不报错、不返回、连工具调用的痕迹都没有。这类"静默失败"的根因在源码里：内置 image_generation 工具有一道认证门控，只对 auth_mode: "chatgpt"（OAuth 登录）开放。API Key 认证的自定义 Provider 压根不会被注入这个工具。
两处关键配置
在 config.toml 的对应 [model_providers.xxx] 段写两行即可绕开门控：
[model_providers.custom]
name = "custom"
wire_api = "responses"
base_url = "https://你的中转地址/v1"
requires_openai_auth = false
env_key = "OPENAI_API_KEY"
http_headers = { "x-openai-actor-authorization" = "local-relay" }
requires_openai_auth = false 让 Codex 不按官方鉴权流程对待这个 Provider；http_headers 里的 x-openai-actor-authorization 是激活开关——Codex 只检查这个头存在且非空，值本身随意（local-relay、local-image-extension 都行）。
配置文件位置：Windows 在 %USERPROFILE%\.codex\config.toml，macOS/Linux 在 ~/.codex/config.toml。API Key 用环境变量喂进去，Windows 的 setx 写注册表后只对新开的进程生效，当前窗口要重开。
改完之后的三步验证
改配置不算完，按这个顺序验收：第一步彻底重启 Codex 并新建会话——旧会话不会重载配置，这是最常见的"改了没生效"原因；第二步在会话里直接要求生成一张测试图，观察是否出现工具调用迹象；第三步若仍无反应，用 --verbose 或日志确认请求头确实带上了那个激活头，同时核对中转服务本身支持 images 端点——门控过了但中转不支持，一样静默失败。
增量提醒（原文未提的两个坑）：一是 wire_api 必须与中转实现匹配——中转只实现了 chat completions 时写 responses 会导致更上游的静默失败，先用 curl 打一次中转的对应端点确认路径存在；二是多 Provider 共存时确认默认 provider 指向正确，profile 机制下容易改了 A 段却跑在 B 段上。这两条加上上面的三步验证，基本覆盖这类问题的全部排查路径。
一点延伸
这类"客户端功能门控"的静默失败在 CLI 工具里越来越常见：功能没开放时直接不注册工具，用户侧看不到任何线索。通用排查心法是把链路拆开验证——配置解析（日志确认段被读取）、工具注册（会话内问"你有哪些工具"）、端点可达（curl 直打）、凭证有效（换 Key 对照）。四段里哪一段断，修哪一段，比对着文档逐项重配快得多。
评论0