现象
- Codex Desktop 模型选择器里
deepseek-v4-flash 显示为 DeepSeek-V4-Flash(连字符),且无法通过 CC 设置里的 displayName 修正;同一批次的 deepseek-v4-pro 显示正常。
- DB(
providers.settings_config.modelCatalog.models[].displayName)里 flash 的 displayName 明明存在(如 Deepseek V4 Flash),但生成的 cc-switch-model-catalog.json / config.toml 里始终是旧值。
- 手动修改生成的 catalog 文件无效:下次同步被覆盖。
根因
enrich_codex_catalog_with_official_metadata(src-tauri/src/codex_config.rs:4646)与 sync_codex_models_cache_with_cc_switch_catalog(同文件 :4686):当 models_cache.json 已被 CC 接管(etag = cc-switch-model-catalog)且 backup 不存在时,read_json_file_if_exists(&backup_path)?.or_else(|| existing_cache.clone()) 会把 CC 自己上一批生成的 cache 当作"官方权威元数据"。
merge_codex_model_entry(:4470)以官方条目为底稿克隆(merged = official_object.clone()),且 codex_official_picker_metadata_field(:4533)规定:官方条目只要有 display_name/displayName,路由条目的 display_name/displayName/description 全部跳过(保留官方值)。
- 结果:一旦某批 cache 里某模型的
display_name 是坏值(例如来自 src-tauri/src/resources/codex_deepseek_catalog_template.json 的连字符写法 DeepSeek-V4-Flash),之后每一批 enrich 都会用该坏值压掉用户设置值——自举锁死,用户设置永远到不了最终文件。
为什么 flash 错、pro 对
cache 里 flash 条目在历史某批被模板坏值写入,pro 条目恰为正确值;此后 merge 一直沿用 cache 值,flash 被永久锁死。
临时修复(已在本机 v3.19.2-7 验证有效)
rm ~/.codex/models_cache.json # CC 生成的 cache(etag=cc-switch-model-catalog)
# 然后在 CC 里切换一次 provider 触发重新同步
重新同步后 cc-switch-model-catalog.json / config.toml 里 display_name 恢复为设置值。
建议修复
enrich_codex_catalog_with_official_metadata(:4646)与 sync_codex_models_cache_with_cc_switch_catalog(:4686):CC 拥有 cache 但 backup 缺失时,官方元数据应视为无(or_else(|| existing_cache.clone()) 改为返回 None),不要拿 CC 自举的 cache 当官方权威。这是最小改动的治本点。
src-tauri/src/resources/codex_deepseek_catalog_template.json 中 deepseek-v4-flash / deepseek-v4-pro 的 display_name 是连字符写法(DeepSeek-V4-Flash / DeepSeek-V4-Pro),产品名应为空格写法(DeepSeek V4 Flash / DeepSeek V4 Pro),建议一并修正,避免坏兜底值继续扩散。
环境
- CCSwitchMulti v3.19.2-7
- macOS aarch64
- Codex Desktop,
model_catalog_json 指向 cc-switch-model-catalog.json
现象
deepseek-v4-flash显示为DeepSeek-V4-Flash(连字符),且无法通过 CC 设置里的displayName修正;同一批次的deepseek-v4-pro显示正常。providers.settings_config.modelCatalog.models[].displayName)里 flash 的displayName明明存在(如Deepseek V4 Flash),但生成的cc-switch-model-catalog.json/config.toml里始终是旧值。根因
enrich_codex_catalog_with_official_metadata(src-tauri/src/codex_config.rs:4646)与sync_codex_models_cache_with_cc_switch_catalog(同文件 :4686):当models_cache.json已被 CC 接管(etag =cc-switch-model-catalog)且 backup 不存在时,read_json_file_if_exists(&backup_path)?.or_else(|| existing_cache.clone())会把 CC 自己上一批生成的 cache 当作"官方权威元数据"。merge_codex_model_entry(:4470)以官方条目为底稿克隆(merged = official_object.clone()),且codex_official_picker_metadata_field(:4533)规定:官方条目只要有display_name/displayName,路由条目的display_name/displayName/description全部跳过(保留官方值)。display_name是坏值(例如来自src-tauri/src/resources/codex_deepseek_catalog_template.json的连字符写法DeepSeek-V4-Flash),之后每一批 enrich 都会用该坏值压掉用户设置值——自举锁死,用户设置永远到不了最终文件。为什么 flash 错、pro 对
cache 里 flash 条目在历史某批被模板坏值写入,pro 条目恰为正确值;此后 merge 一直沿用 cache 值,flash 被永久锁死。
临时修复(已在本机 v3.19.2-7 验证有效)
重新同步后
cc-switch-model-catalog.json/config.toml里display_name恢复为设置值。建议修复
enrich_codex_catalog_with_official_metadata(:4646)与:4686):CC 拥有 cache 但 backup 缺失时,官方元数据应视为无(sync_codex_models_cache_with_cc_switch_catalog(or_else(|| existing_cache.clone())改为返回None),不要拿 CC 自举的 cache 当官方权威。这是最小改动的治本点。src-tauri/src/resources/codex_deepseek_catalog_template.json中deepseek-v4-flash/deepseek-v4-pro的display_name是连字符写法(DeepSeek-V4-Flash/DeepSeek-V4-Pro),产品名应为空格写法(DeepSeek V4 Flash/DeepSeek V4 Pro),建议一并修正,避免坏兜底值继续扩散。环境
model_catalog_json指向cc-switch-model-catalog.json