我们团队修复了 Codex 升级到 GPT 后，客户端无法生图的问题

我们团队修复了 Codex 升级到 GPT 后，客户端无法生图的问题

先运行脚本

如果你遇到“Codex 能聊天，但不能生图”，先按下面步骤执行。当前仓库脚本针对 macOS，Windows 不能直接运行这份.sh：

gitclonehttps://github.com/xianyu110/codex-imagegen-relay-fix.git
cdcodex-imagegen-relay-fix
chmod 700 fix-codex-imagegen-macos.sh
./fix-codex-imagegen-macos.sh

脚本会读取本机已有的~/.codex/auth.json，只检查OPENAI_API_KEY是否存在，不会把 Key 打印出来，也不会写入配置文件。中转地址不是默认地址时，在运行前设置：

CODEX_RELAY_BASE_URL='https://codex.maynor1024.live/v1'./fix-codex-imagegen-macos.sh

脚本显示验证通过后，完全退出 Codex（包括后台进程），再重新启动并新建任务。对话主模型使用支持工具调用的模型，例如gpt-5.4；不要把主模型改成gpt-image-2，图片会由内置image_gen工具自动调用。

如果脚本提示OPENAI_API_KEY(auth.json)=MISSING，不要把 Key 粘贴到聊天或命令行参数中，应在本机通过安全输入流程写入用户环境后再重试。Windows 用户请参考同一仓库的配置原则，使用 Windows 用户级环境变量和新进程验证；本文的完整脚本验证是在 macOS 上完成的。

先说结论

这次故障表面上是“升级到 GPT 后不能生图”，本质上不是 GPT 模型没有图片能力，而是三段链路没有对齐：对话模型、Responses API 中转、Codex 内置image_gen。

我们团队没有修改 Codex 二进制，也没有切换回 OpenAI 官方 provider。最终方案是在现有自定义 provider 上做最小配置修复，让环境变量负责 Bearer 鉴权，让固定的 actor header 满足内置工具的可见性门控，再通过用户级启动项确保桌面应用能继承环境变量。

这套方案已经在当前 macOS 设备上实测通过。文章不会把 macOS 实测结果包装成 Windows 已验证结论；Windows 用户需要按同样的链路检查环境变量和桌面进程继承关系。

故障现场：聊天能用，图片不行

最开始的现象很容易误导人：Codex 可以正常对话、写代码，甚至直接请求/v1/responses也能返回结果，但要求它画图时，image_gen不可见、调用失败，或者没有本地 PNG 产物。

我们先排除了“模型不存在”这个猜测。中转的/v1/models返回 HTTP 200，模型列表同时包含gpt-5.4和gpt-image-2。接着用gpt-5.4请求/v1/responses，同样返回 HTTP 200。

因此，问题不是中转完全不可用，也不是把图片模型误当成了聊天主模型。正确关系应该是：

Codex 对话模型（例如 gpt-5.4） | +--> 内置 image_gen 工具 | +--> 中转调用 gpt-image-2 | +--> 本地 PNG 文件

真正卡住我们的三个点

1. 官方鉴权门控和自定义 provider 冲突

当前版本的内置图片工具仍会检查 provider 是否要求官方鉴权。自定义中转如果保留了requires_openai_auth = true，就可能让工具被隐藏或拒绝调用。本次实测的image_generation已是 stable/default 开启状态，因此不需要修改二进制或增加额外插件。

我们确认当前版本可复用的组合是：

requires_openai_auth = false http_headers = { "x-openai-actor-authorization" = "local-relay" }

这里的local-relay只是非空静态占位值，不是凭据。中转服务应忽略或剥离这个 header，不能把它当成真实授权信息。

2. API Key 应由环境变量提供

provider 使用env_key = "OPENAI_API_KEY"，Codex 才会在请求时以 Bearer 方式读取密钥。我们删除了同一 provider 下旧的auth = { command = ... }和 Node helper 引用，避免两套鉴权来源互相覆盖。

密钥只从本机已有的auth.json或安全输入流程注入用户环境，不写进config.toml、脚本、日志或仓库。排查时也只输出存在/不存在状态。

3. 终端变量不等于桌面应用变量

这一步最容易被忽略。终端里的export OPENAI_API_KEY=...只影响当前 shell；从 Finder、Launchpad 或后台启动的 Codex Desktop 进程，可能根本看不到这个变量。

我们的 macOS 一键脚本安装了用户级 LaunchAgent，在登录时从auth.json读取密钥并用launchctl setenv注入。脚本本身不保存密钥，只负责让新启动的 Codex 子进程继承环境。

最小配置

最终 provider 保留了原有无关配置，只调整了鉴权、Responses 协议和图片功能：

[model_providers.maynoraicodex] name = "maynoraicodex" base_url = "https://codex.maynor1024.live/v1" wire_api = "responses" requires_openai_auth = false env_key = "OPENAI_API_KEY" http_headers = { "x-openai-actor-authorization" = "local-relay" }