[Bug]: Codex 模型目录缺失 GPT-6 系列（client_version 硬编码为 0.153.0）
维护者通常 1 天内回复
已经有一个关联 PR 被合并了。
- #477 来自 @yujiachen-y —— 已合并
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 65/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- javascript, typescript
调研方向
从 codex-model-discovery.js 开始，该文件第 3 行设置了常量 CODEX_CATALOG_CLIENT_VERSION，然后检查该值如何以 client_version 的形式发送到 models 端点。接着阅读 mergeCodexModels，确认获取到的模型与已存储的模型如何合并。当目录返回所列的全部 7 个模型并附带当前的客户端版本，或者发现代码动态获取版本，并且已存储配置的覆盖行为仍与 issue 所述一致时，即为完成。
由索引模型根据 Issue 内容生成。
描述
Product or interface
Desktop app
Version
3.1.1 (Electron 42.8.0)
Platform
Windows — Windows 11 x64 (10.0.26300)
Issue area
Other
Desktop log upload ID
(不适用)
Steps to reproduce
- 完成 Codex OAuth 连接
- 设置 → 用量与模型 → 点击「获取模型列表」
- 观察「OpenAI Codex」分组下的模型数量
复现稳定性：稳定，可确定性复现。
Expected and actual behavior
期望： 返回账号可用的全部 7 个模型。
实际： 只返回 4 个，缺失 GPT-6 系列 3 个：
| 已显示 | 缺失 |
|---|---|
gpt-6-astra |
gpt-6.1-sol |
gpt-5.6-sol |
gpt-6-sol |
gpt-5.6-terra |
gpt-6-luna |
gpt-5.6-luna |
且界面不提示列表可能不完整，用户会误以为账号只有这些模型。
根因
codex-model-discovery.js 第 3 行的常量在构建期硬编码：
const CODEX_CATALOG_CLIENT_VERSION = '0.153.0';
OpenAI 后端按 client_version 分级下发模型目录，0.153.0 属于较早档位，因此只返回部分模型。
建议： 使用当前的 client_version，或从上游动态获取，避免构建期快照过期。
Redacted error summary
不适用（无运行时错误，纯数据问题）。以下为对照实验数据 —— 使用同一份 OAuth 凭证，仅改变 client_version 查询 https://chatgpt.com/backend-api/codex/models?client_version=<v>：
client_version | visibility=list 的模型数
----------------+---------------------------
0.153.0 | 4 <-- 当前使用的值
0.160.0 | 7
0.162.0 | 7
0.170.0 | 7
0.200.0 | 7
1.0.0 | 7
交叉印证：同机 Codex CLI 使用 client_version = 0.162.0，其模型缓存中 7 个模型齐全，且 gpt-6.1-sol 排在 priority 1。
Screenshots
可提供（模型列表仅 4 项的截图）。请告知是否需要。
Additional context
- 临时绕过方式：手工在
config.yaml的custom_provider.openai-codex.models下补充缺失条目。已验证mergeCodexModels中 stored 字段优先（源码注释 "Stored fields are authoritative"），补充后不会被后续刷新覆盖。但此方式无法自动发现后续新模型，且若后端调整上下文长度或推理档位，存储值会覆盖服务端更新而停留在旧值。 - 相关但不同的 issue：#464 讨论映射层缺少 ultra 档位与 Fast/priority 服务层，属于「接口拿到了但没接」；本 issue 是「目录接口本身就没拿到完整列表」。根因与修法均不同，故单独提交。
- I have searched existing issues.
- I have included my version and removed sensitive information.
- 主要语言
- TypeScript
- 星标
- 2k
- 派生
- 254
- 平均合并
- 8 小时 12 分钟
- 30 天内合并 PR
- 149
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
MiniMax-AI/minimax-code 的其他 Issue
-
bug needs-triage tui
难度 2/5 1-3 小时 新手友好度 72/100
MiniMax-AI/minimax-code#481 · 1 条评论 ·
维护者通常 1 天内回复
-
bug cli documentation needs-triage
难度 2/5 1-3 小时 新手友好度 84/100
MiniMax-AI/minimax-code#299 · 3 条评论 ·
维护者通常 1 天内回复
-
bug cli needs-triage
难度 2/5 1-3 小时 新手友好度 78/100
MiniMax-AI/minimax-code#128 · 2 条评论 ·
维护者通常 1 天内回复
-
bug desktop
难度 2/5 1-3 小时 新手友好度 82/100
MiniMax-AI/minimax-code#87 · 2 条评论 · 2 个 reaction ·
维护者通常 1 天内回复
-
bug desktop needs-triage
难度 2/5 1-3 小时 新手友好度 68/100
MiniMax-AI/minimax-code#80 ·
维护者通常 1 天内回复
查看 MiniMax-AI/minimax-code 的全部 Issue
相似的 Issue
-
priority:high
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
immich-app/immich#32426 ·
维护者通常 1 天内回复
-
documentation good first issue hacktoberfest help wanted
难度 2/5 1-3 小时 新手友好度 78/100
libredb/libredb-studio#1756 ·
维护者通常 1 天内回复
-
state:triage-needed
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复