[Bug] Codex 内置工具 oneOf schema 使 DeepSeek 路由 /responses 整请求 422：建议 fail-open + 探测误选回查

[rvvrvrv]

摘要 / Summary

Codex 桌面版内置插件 codex-app-tools 的工具 codex_app__automation_update 携带 parameters.anyOf[1].oneOf（分支不可证明互斥）的工具 schema。当路由目标为 DeepSeek 这类"严格 OpenAI 兼容"上游、且协议探测选用了 Moonshot MFJS 工具 schema 方言时，MFJS 编译器对整个请求 fail-closed，返回 422——一个默认插件的单个工具 schema 形态会杀死经代理的所有工具会话，与 v3.18 修复的 parameters: null 属同一类问题（本轮为 Codex 新版把该工具升级为真实 schema 后复发）。

English: One Codex built-in tool (codex_app__automation_update) carries a non-disjoint anyOf/oneOf parameter schema. Under the Moonshot MFJS tool-schema dialect chosen by protocol probing for strict upstreams like DeepSeek, the MFJS compiler fails the entire /responses request with 422. This is the same class as the v3.18 parameters: null fix (#4706/#5315), now recurring because a newer Codex build gives the tool a real schema. Suggest fail-open-with-event for unrepresentable tool schemas, plus a probe recheck (below).

版本 / Version

• CCSwitchMulti: v3.19.2-26（Windows Portable）
• Codex 桌面版: 26.901.x（内置插件 codex-app-tools@openai-bundled 0.1.3）
• 操作系统: Windows
• 涉及应用: Codex

重现步骤 / Steps to Reproduce

1. MultiRouter 路由（如 "Codex GPT + DeepSeek"）目标供应商选 DeepSeek，模型 deepseek-v4-flash-vision-exp；进行过协议探测，探测档案记录的工具 schema 方言为 Moonshot MFJS（或该卡协议探测后自动采用 MFJS）。
2. Codex 桌面版启用内置插件 codex-app-tools@openai-bundled（默认启用），注册 MCP 服务 codex_app（工具：automation_update、create_thread、send_message_to_thread、fork_thread、handoff_thread）。
3. 任意会话发一条消息（请求会自动携带该工具列表）。

实际结果：请求重连 5/5 后返回：

unexpected status 422 Unprocessable Entity: CC Switch local proxy failed while handling
Codex endpoint /responses. Provider: Deepseek; model: deepseek-v4-flash-vision-exp;
cause: 请求/响应转换错误: tool `automation_update` schema at
`$.tools[9].tools[0].parameters.anyOf[1].oneOf` is incompatible with Moonshot MFJS:
oneOf can only be represented as MFJS anyOf when every branch is provably disjoint

期望行为：单个工具 schema 无法安全表示时，不应让整个请求 422。应降级/豁免该工具（如非互斥 oneOf → anyOf + 该工具 strict: false），并记录结构化事件；会话应当照常可用。

根因 / Root Cause

• codex_tool_schema.rs 的 MfjsCompiler::compile_object：oneOf 分支若不能证明两两互斥，直接 Err（fail-closed），错误穿透到整个请求。
• 该工具 schema 来源是 Codex 侧（openai-bundled codex-app-tools/desktop-mcp.json），其形态不受 CCSM 控制；Codex 桌面版更新即可改变形态（v3.18 时该工具还是 parameters: null，本轮已是真实 anyOf + oneOf，因此同类问题会随 Codex 更新复发）。

建议 1：fail-open + 事件（治标且可发布）

与现有"down-level 注释/格式标注则置 strict: false 保留工具"的哲学一致（codex_tool_schema.rs 已有先例，见 annotations 注释），建议把"不可证明互斥的 oneOf"同样降级为 anyOf + relaxed（工具 strict: false）而不是报错；空 oneOf 仍可保留 fail-closed。改动很小：

// codex_tool_schema.rs: compile_object() 内 oneOf 分支
if !one_of_branches_are_pairwise_disjoint(branches) {
    self.relaxed = true; // 降级为 anyOf + strict:false，替换原 Err
}

格式更激进的“整请求 fail”可改为：记录 redacted 事件（参考已有的 hosted_tool_not_called / dropped-tool 结构化日志），仅豁免该工具，不让 422 打到 Codex。

（我本地已按此改过并验证思路：DeepSeek 路由切手动覆盖 + 工具 Schema=OpenAI JSON Schema 直传可用，说明 MFJS 收紧并非 DeepSeek 必需。）

建议 2：回查探测为何对 DeepSeek 选 MFJS（可能的根治）

protocol_compatibility/runner.rs should_retry_with_moonshot 的触发条件之一是"forced tool 调用未返回有效结果"（模型未调用），而不只是"上游拒绝 schema"（400/422）。DeepSeek 已实证接受原始 OpenAI schema（手动 openai 直传正常），MFJS 很可能是当初探测时模型未返回工具调用被误升的。建议：

• 仅当上游明确拒绝 schema（400/422）时才升级到 Moonshot MFJS；
• 模型未调用强制工具时重试但不切换方言。

若此点修正，DeepSeek 等严格上游可能根本不需要 MFJS 编译器，该类 422 自然消失。

临时 Workaround（已在生产验证）

目标供应商卡 → 高级选项 →「协议配置方式」= 手动覆盖（高级） →「工具 Schema」= OpenAI JSON Schema，保存后重启 Codex。注意：仅当协议配置方式为手动且「最终使用协议」与探测 transport 一致时才写入 meta（codexProtocolSettings.ts buildCodexProtocolMeta 的 !matchesProbeTransport 会静默不写入）；表单默认显示的 "OpenAI JSON Schema" 是读取缺省回退值，不代表已生效。

[255255ast]

感谢楼主，这个 issue 帮了大忙。
我这边是 CCSwitchMulti v3.19.2-29 + Zhipu GLM 5.3 Flash + Codex Multi-Agent V2，之前一直报 422，错误点在 agents_followup_task 的 message.encrypted，提示与 Moonshot MFJS 不兼容。

一开始我看到界面里显示的是 OpenAI JSON Schema，还以为已经生效，后来按你这里的方法把“协议配置方式”从自动探测改成手动覆盖，明确指定 Chat Completions + OpenAI JSON Schema，问题立刻解决了。

看起来确实是自动探测结果和界面显示不完全一致导致的。再次感谢，省了我继续折腾配置和代码定位的时间。

[ed-lee-aaa]

补充一组 v3.20.1-1（当前最新正式版） 下的同类复现证据，与楼主场景同一根因——自动探测把「原生接受 OpenAI Schema 的上游」误升为 Moonshot MFJS 方言，且 MFJS 编译器 fail-closed——但触发工具与错误路径不同，可确认该问题在最新版仍未修复。

环境

• CCSwitchMulti v3.20.1-1（Windows x86_64）
• Codex 桌面版 26.901.41600
• 普通 Codex Provider（非 MultiRouter）直接走本地路由/接管（127.0.0.1:15721），供应商 DeepSeek（api.deepseek.com），模型 deepseek-v4-flash / deepseek-v4-pro / deepseek-v4-flash-vision-exp

现象

任意会话发消息即失败，cc-switch.log 循环报：

[FWD-003] Provider DeepSeek 请求失败: 响应转换失败: tool `followup_task` schema
at `$.tools[8].tools[0].parameters.properties.message.encrypted` is incompatible
with Moonshot MFJS: encrypted is not supported by Moonshot MFJS

连续 4 次失败后熔断打开，路由彻底不可用：

[CB-004] 熔断器触发: 连续失败 4 次 → Open

请求未发到上游（纯本地转换阶段 fail-closed），DeepSeek 侧无任何调用。

DB 证据（自动探测档案 protocol_compatibility_profiles 表）

对 DeepSeek 三个模型各有一条：

transport: open_ai_responses, readiness: verified
tool_schema_dialect: moonshot_mfjs
tool_schema_evidence: ambiguous_rejection
adaptations: [{ trigger: ambiguous_request_rejection, change: tool_schema_moonshot_mfjs, outcome: verified }]

即探测时遇到一次「模糊拒绝」就把 DeepSeek 永久锁进 MFJS 方言（直到手动删除档案）。

为什么 MFJS 对 DeepSeek 是多余且有害的

用同一 API Key 直连 https://api.deepseek.com/v1/responses 实测：携带含 encrypted 标记的
followup_task / spawn_agent 嵌套工具 Schema（string、boolean 两种形态）均返回 HTTP 200，
DeepSeek 原生接受 OpenAI JSON Schema。
→ MFJS 收紧对 DeepSeek 并非必需；一旦被选中，Codex Multi-Agent V2 的工具
（followup_task / spawn_agent / automation_update …）都会在本地转换阶段被杀。

已生效的临时解法（与楼主第 2 点结论一致）

• DeepSeek 供应商 meta 写入 codexProtocolMode=manual、codexToolSchemaDialect=openai、codexHistoryReplay=native_only
  （等价于 UI：协议配置方式=手动覆盖 + 工具 Schema=OpenAI JSON Schema）
• 同时删除该供应商 3 条 moonshot_mfjs 自动探测档案
• 重启 CC Switch Multi 后路由恢复正常，不再出现 FWD-003 / CB-004

对根治的建议（支持楼主「建议 2」，并补充一点）

1. protocol_compatibility/runner.rs 的 should_retry_with_moonshot：
   仅当上游明确以 400/422 拒绝 Schema 时才升级 MFJS；探测中「模型未调用强制工具」等
   模糊信号不应切换方言（DeepSeek 很可能就是这样被误升的，且其原生 /responses 已实证可用）。
2. MFJS 编译器遇到无法表示的字段/结构（未知关键字如 encrypted、不可证明互斥的 oneOf）应 fail-open：
   降级/豁免该工具并记录结构化事件，而不是让整请求失败。Codex 桌面版更新会不断引入新工具形态，这类问题会持续复发。