[Bug][Codex] 菜单白名单未注入窗口内官方同名模型可被选中，会话线程级静默钉死官方 provider（附完整时间线与兜底建议）

[zhushihao]

环境

• CCSwitchMulti 3.19.2-18.4（macOS，arm64，代理接管模式，codex-multirouter 档位）
• ChatGPT.app 26.825.41651，内置 codex-cli 0.151.0-alpha.7.1（15:59 自动更新前为 0.150.0-alpha.12.2，问题在两个版本上都存在）
• 多代理 V2 + 自定义角色（~/.codex/agents/*.toml，角色内声明 model_provider = "codex_model_router_v2"）

现象

2026-08-29 15:04 新建的 Codex 会话在 session_meta 中被直接钉死 model_provider = "openai"（官方），且线程级粘滞。16:04 该会话 spawn 声明了第三方模型角色的子 Agent 时，子 Agent 继承官方 provider，把第三方模型名直发 chatgpt.com 后端，得到 400：

{"type":"error","status":400,"error":{"type":"invalid_request_error",
"message":"The 'glm-5.3-flash-4faa657f-1e92-467e-b3b0-d446aeb27b9a' model is not supported
when using Codex with a ChatGPT account."}}

当天 24 个线程里只有 2 个是官方 provider：15:04 的父线程和它 16:04 的子任务；前后几分钟内创建的所有其他线程（含 subagent）均为 codex_model_router_v2，全局接管状态正常。

时间线（本机日志可完整复盘）

时间	事件
12:49–14:20	CCSM 多次重启（12:49、12:51×2、12:59 异常退出恢复、13:12、13:13、13:15 异常退出、13:36、13:42、13:50、13:55、14:00、14:20），每次都伴随"恢复 Live 配置 → 重新接管"窗口
~13:06	Codex 桌面端被重启，但不是从 CCSwitchMulti 启动
14:00:47 / 14:20:32	守护两条 WARN：Codex Desktop 模型菜单白名单未注入: Codex App is already running without an injectable CDP port. Fully quit Codex, then launch it from CCSwitchMulti...
15:00–15:04	代理接管正常（codex-router.log 持续转发其他会话请求，5 分钟 114 个 request_prepared）
15:04:04	新会话创建，session_meta.model_provider = "openai"，model 选的是与官方同名的 gpt-5.6-luna；15:34/16:02/16:03 三次 thread_settings 重申 model_provider_id: "openai"
16:04:10	该会话 spawn GLM 角色 → 子任务继承官方 provider → 400（上游 openai/codex#40858：角色文件中的 model_provider 被客户端静默丢弃，model 却生效）
15:50:47	白名单注入恢复成功（models=8）；此后再无官方线程
16:44+	同一 GLM 模型走路由全部 200，排除模型 ID、认证、上游兼容性问题

关键对照：失败的子任务 session 在 codex-router.log 中 0 次命中（请求根本没经过 15721）；同一分钟另一个会话把同一个 GLM 模型名走路由是 200。

根因（两条通道）

通道 A（本次实际触发）：菜单白名单注入失败期间，原生菜单里的官方同名模型可选。
gpt-5.6-luna/sol/terra 与官方模型表同名（multirouter 自己就把 luna 路由到 OpenAI_Official）。白名单注入成功时菜单只出 CCSM 目录（models=7/8，不含官方条目）；注入失败时退回原生菜单，选中官方同名条目即创建出 model_provider = "openai" 的线程。线程级 provider 粘滞，全局配置对它永久失效。

通道 B（结构性隐患）：接管解除窗口内，config.toml 恢复为无 model_provider 的原始配置。
proxy_live_backup.original_config（136 行）中没有任何 model_provider 行。Codex 在缺省 model_provider 时默认内置 openai。因此每次 CCSM 重启的"恢复 Live 配置 → 重新接管"窗口内，新建会话都会落到官方。今天 12:49–14:20 约有 10 次这样的窗口（17:59、18:10 又各出现一次）。

已排除人为切档：当天两次热切换（14:25:07、15:54:54）目标均为 codex-multirouter，无任何切到 codex-official 的记录。

复现步骤

1. 代理接管 + codex-multirouter 档位正常运行；
2. 直接退出并重新打开 Codex 桌面端（不从 CCSwitchMulti 启动），日志出现"模型菜单白名单未注入"WARN；
3. 新建会话，模型选与官方同名的目录模型（如 GPT-5.6-Luna）→ 该会话被钉死在官方 provider（可用任意会话内报错或 rollout 的 session_meta 验证）；
4. 在该会话中 spawn 声明了第三方模型的自定义角色 → 上游 Native subagent ignores explicit model_provider override while model override works openai/codex#40858 使角色的 model_provider 被忽略 → 第三方模型名直发官方后端 → 400。

修复建议（按优先级）

1. 注入失败告警升级：模型菜单白名单未注入 目前只写日志，用户无感知。建议升级为系统通知 + 托盘红点 + 主界面横幅，并在守护检测到"App 运行但无 CDP 端口"时周期性重试/引导。
2. 代理层兜底告警：直连 chatgpt.com 的请求若携带 CCSM 目录中的非常规模型名（glm-* / deepseek-* / k3-* 等），立即告警并记录。"官方通道上出现第三方模型名"是这类事故的独家指纹，可在 spawn 当场暴露，而不是事后翻 rollout。
3. 恢复后校验：热切换/接管恢复完成后校验 config.toml 的 model_provider 是否符合当前档位预期，不符则告警（与 Codex v2 未命中路由应与前端提示统一为 fail-closed #56 fail-closed 思路一致）。
4. （可选）消除同名碰撞：目录内与官方同名的模型在菜单显示名上加可辨识后缀（如 "Luna·CCS"），注入失败时也能肉眼区分两个条目。
5. （可选，评估语义影响）通道 B 兜底：原始配置缺 model_provider 时，恢复 Live 配置是否可保留指向本机 router（或至少在恢复事件中提示"接管解除期间新建会话将默认官方"）。

关联

• 上游 Native subagent ignores explicit model_provider override while model override works openai/codex#40858（角色 model_provider 被静默丢弃，model/model_reasoning_effort 生效）——CCSM 侧无法修，本 issue 的 1/2/4 都是围绕它的兜底。
• 与 MultiRouter 模型匹配语义缺陷：include 反选被前缀放行 / 无匹配 fallback 官方 / mode=all 无前缀路由模型误判不可路由 #34、[Bug][Codex V2] v3.19.2-14 新格式 routes（matchPrefixes）不被 codex_route_has_prefix_model_match 识别，所有模型 fallback 到官方 route，子 Agent 全部误判为 Official #29（路由未命中 fallback 官方）、Codex v2 未命中路由应与前端提示统一为 fail-closed #56（fail-closed）同属"静默落到官方"家族，但本问题发生在 codex 客户端选 provider 层，路由器根本没有收到请求，现有 fail-closed 逻辑覆盖不到。

（本报告所有证据均来自本机 ~/.codex/sessions、~/.codex/state_5.sqlite、~/.cc-switch/logs/、CCSM 数据库，已脱敏。）