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

我们团队修复了 Codex 升级到 GPT 后客户端无法生图的问题先运行脚本如果你遇到“Codex 能聊天但不能生图”先按下面步骤执行。当前仓库脚本针对 macOSWindows 不能直接运行这份.shgitclonehttps://github.com/xianyu110/codex-imagegen-relay-fix.gitcdcodex-imagegen-relay-fixchmod 700 fix-codex-imagegen-macos.sh./fix-codex-imagegen-macos.sh脚本会读取本机已有的~/.codex/auth.json只检查OPENAI_API_KEY是否存在不会把 Key 打印出来也不会写入配置文件。中转地址不是默认地址时在运行前设置CODEX_RELAY_BASE_URLhttps://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 上完成的。Codex 图片生成修复封面先说结论这次故障表面上是“升级到 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 文件Codex 内置 image_gen 调用链路真正卡住我们的三个点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_KEYCodex 才会在请求时以 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 }[features]image_generation true主模型仍然使用支持工具调用的gpt-5.4。不要把 Codex 的对话主模型改成gpt-image-2图片模型由内置工具在需要时调用。一键修复脚本做了什么仓库里的fix-codex-imagegen-macos.sh按顺序完成四件事重新读取现有config.toml只合并目标 provider 和[features]避免重复 section。清除旧的 command auth 和 Node helper 引用确保env_key是唯一鉴权入口。配置 LaunchAgent让桌面进程在下次启动时继承用户级OPENAI_API_KEY。在不使用 Node 或 Python 的情况下检查/v1/models、/v1/responses、gpt-image-2、gpt-5.4和配置幂等性。实际脚本验证结果为shell_syntaxOK、models_http200、gpt-image-2AVAILABLE、gpt-5.4AVAILABLE、responses_http200、config_idempotenttrue。最终验证让内置工具真的生成文件接口检查通过后我们使用 Codex 原生可执行路径对应的桌面 CLI 子进程注入用户作用域环境变量创建一次临时任务并明确要求只调用一次内置image_gen生成“白底居中蓝色圆形”的诊断图。验证要求禁止 shell、Python、SVG、Canvas 和外部图片工具。最终内置工具可见并完成调用产生本地 PNG。随后又生成了一张橘猫图作为文章中的真实产物示例修复后由内置 image_gen 生成的橘猫这张图不是手工绘制也不是脚本拼出来的它来自 Codex 内置图片工具的实际输出。安全边界和限制这次修复解决的是 provider 配置、鉴权注入和工具门控不代表第三方中转天然可信。中转服务仍可能记录请求、提示词或图片涉及内部代码、客户资料和未公开方案时必须先确认服务方的数据处理策略。另一个边界是平台差异本次完整链路在 macOS 上验证通过Windows 的 User/Machine 环境变量和桌面进程继承机制不同不能直接把 macOS LaunchAgent 当成 Windows 修复方案。Windows 应使用对应的用户环境变量写入和新进程验证流程但原则仍然是“密钥走环境变量Codex 使用自定义 provider图片由内置工具调用”。写在最后我们最后修好的不是某一个“神奇参数”而是调用链的边界工具可见性 - requires_openai_authfalse 非空静态 actor header 请求鉴权 - env_keyOPENAI_API_KEY 接口协议 - wire_apiresponses /v1 桌面继承 - 用户级环境变量 完全重启 Codex 图片调用 - 对话模型调用内置 image_gen再由中转访问 gpt-image-2所以遇到“Codex 升级后能聊天但不能生图”时不要先反复更换 API Key。先分别验证模型列表、Responses、provider 门控和桌面进程环境再做最小修改通常更快也更安全。项目地址https://github.com/xianyu110/codex-imagegen-relay-fix