切引擎到 Codex/GPT-5.5 时，历史 input[].id 超过 64 字符导致 400 string_above_max_length

[mp55]

问题描述 / What happened

同一条对话里，从 Gateway 模型（如 x-ai-grok/grok-4.6）切到 Codex/OpenAI Responses 模型（如 codex/gpt-5.5）并 resume 原 thread 后，下一轮请求失败。

原因：Gateway 历史里的 item id（尤其 ws_* / tco_*）长达 84/85 字符。切到 Codex 后这些 id 被原样塞进 Responses API 的 input[n].id。OpenAI 限制该字段 ≤ 64 字符，LiteLLM 把上游 400 原样包回客户端。

这不是用户输入问题，也不是上下文超长。同一条会话里重试、compact 都会继续失败。

根因
OpenAI Responses API 校验 input[n].id 最长 64。

Gateway 历史里实际 id 形如：

ws_0cb4cb13-dee8-9afb-aece-c5ec0b3bf2bf_call-94cd3890-d2bb-41ae-8c39-9613c70a322c-24 # 84
tco_0cb4cb13-dee8-9afb-aece-c5ec0b3bf2bf_call-94cd3890-d2bb-41ae-8c39-9613c70a322c-24 # 85

结构：{prefix}_{uuid}_call-{uuid}-{n}

ws_ = 3，总长 84
tco_ = 4，总长 85
这条 rollout 里至少 8 个超长 id。input[74] 说明是长会话回放，不是单条新消息。

Grok 自己能吃这些 id；切到 Codex 后未做 remap/truncate，请求被 OpenAI 拒绝。
同源问题（建议一并修）
同一类「切引擎不改编历史 id」还有前缀校验失败：

Invalid 'input[18].id': 'fc_24d4b468-46a3-9c15-b839-7ee1978b7f4a_0'. Expected an ID that begins with 'ctc'.

以及 compact 同样失败：

Error running remote compact task: ... Invalid 'input[35].id': ... expected 64, got 83

说明问题在历史序列化 / resume / compact 公共路径，不只是普通 turn。

环境 / Environment

Cindy Desktop 0.1.77（win32-x64 hotfix）
Codex CLI 0.153.4
OS：Windows
复现会话：910f32c3-0fe4-41c6-bc4a-bb33a22fca46
thread：01a08a53-1702-72e3-bc2f-cd4d836ed99f

复现步骤 / Steps to reproduce

1. 新建对话，引擎选 x-ai-grok/grok-4.6（cindy_gateway）
2. 进行多轮，触发工具调用（尤其 web search）
3. 同一条会话切到 codex/gpt-5.5（cindy_codex），resume 原 thread
4. 再发一条消息（内容无关，复现时发了 111）

日志与截图 / Logs & screenshots

关键日志：

startSession model=x-ai-grok/grok-4.6 provider=cindy_gateway resume=new
thread/start ok threadId=01a08a53-1702-72e3-bc2f-cd4d836ed99f modelProvider=cindy_gateway

startSession model=codex/gpt-5.5 provider=cindy_codex resume=01a08a53-1702-72e3-bc2f-cd4d836ed99f
thread/resume ok modelProvider=cindy_codex

codex turn error string_above_max_length input[74].id expected 64 got 84

[dash-s-cindy]

**判断：**同一对话切换模型后继续使用历史，是需要保留的用户能力；本报告中恢复 thread 后下一轮请求被拒绝，值得按历史请求兼容性缺陷推进。提报日志显示 thread/resume 已成功，失败发生在后续请求的 input[n].id 校验阶段，因此应优先检查历史项与目标接口的兼容性，而不是要求用户修改本轮输入或缩短提示词。

**行动：**先建立脱敏历史回归样例，定位普通 turn 和 remote compact 的实际出站请求及 ID 转换位置，再确定修复落点。当前尚未完成源码及真实请求验证，也未确认 main 快照 abcf92c2b34e99209e505662a3fe4e11868e8aa1 是否已包含修复；暂不能将其归为已修复待发布，或承诺升级即可解决。

现有证据支持什么

1. **长度问题有具体线索。**正文给出的 ws_*、tco_* 示例长度分别为 84、85 字符，与日志中的 string_above_max_length、input[74].id、expected 64 got 84 相吻合。这支持“目标请求中的某个历史 item ID 不符合接口约束”的判断，但完整请求尚未取得，ID 的生成方、是否原样回放，以及 LiteLLM 在链路中的具体行为仍待确认。
2. 前缀报错不能只靠截断解决。fc_* 被要求以 ctc 开头，需要结合该项实际 type、工具名称及相邻调用/结果判断。它可能涉及目标 item 类型的 ID 规则，也可能涉及工具调用类型转换；仅凭错误文本，不能认定把所有 fc_ 改成 ctc 就是正确修复。
3. **compact 必须单独覆盖。**正文另有 remote compact 的超长 ID 报错，足以将它纳入复现与验收范围，但不足以证明它和普通 turn 使用同一个序列化函数。不能只修常规发送入口后就宣布问题解决。

这些证据来自提报材料，尚未独立运行复现。本轮检索未取得足以建立重复报告、直接修复依赖或发布状态关联的记录，因此不列弱相关 Issue/PR。

建议的排查与修复路径

1. **建立最小样例并确认责任层。**保留工具调用和结果配对，去掉私人文本；对照 Gateway 历史项、切换后读取的历史项和最终请求项，定位是哪一层生成、保留或转换 id。分别检查普通 turn 与 remote compact，避免把改动放在未覆盖实际请求的 UI 或错误展示层。
2. **验证目标接口的 item 契约。**按失败项的实际 type 确认长度、前缀、ID 是否必填及引用规则，并区分 item id 与工具关联 call_id。不要全局删除 ID、统一替换前缀或直接截断所有字段。
3. **若确认需要重映射，优先采用请求侧适配。**按目标 item 类型生成稳定、满足约束且低碰撞的短 ID，并同步处理确实引用该 ID 的字段。若涉及 call_id，必须保持调用与结果的一一对应。优先保留原始历史不变，确保已有失败会话无需手工编辑历史文件即可再次尝试。
4. **保留现有切换能力。**目前没有证据支持通过禁止模型切换、强制清空历史或强制新建 thread 作为正式修复。对请求的适配方案还需验证语义完整性，不能以“接口不再返回 400”作为唯一成功标准。

验收范围

• Gateway 多轮工具历史 → 目标 Codex 模型 → resume → 下一轮成功，且模型仍能正确使用先前工具结果。
• 覆盖 64/65 字符边界、报告中的 84/85 字符样例，以及开头相同但末尾不同的长 ID，检查碰撞与配对。
• 对前缀报错保留实际 item 类型，验证正确的类型与 ID 组合，而非仅让长度合规。
• 普通 turn、remote compact、compact 后继续对话分别通过。
• 已有失败会话、重复 resume、重试及切回原模型不破坏历史、引用或工具调用配对。
• 在报告所用 Windows 环境及实际发布的 Codex 组件组合上确认；源码或单元测试通过不能替代发布组合验收。

还需要的材料与临时处理

请补充失败项及相邻调用/结果的脱敏 type、id、call_id、实际请求端点，以及复测时 Desktop/Codex 组件版本。无需公开整份 rollout、私人对话、令牌或工具返回内容。

在修复确认前，可尝试新建目标模型会话并手动带入必要摘要，避开原始问题历史；这不是完整历史迁移，也尚未在该复现会话验证。对于同一条 ID 校验错误，不建议把反复重试或 compact 当成已知有效的恢复办法。

[FicoHub]

在当前 main(2026-09-10,6ef14c53a)上核对了代理层的处理现状,分两部分:

前缀错配(fc_ → Expected ctc)与 compact 同类失败:#4129「fix(codex): 修复切换压缩工具 ID 错配及独立代理恢复」已于 2026-09-09 02:49 +0800 合入 main(10928e638),按 item 最终类型校正 fc_/fco_/ctc_/ctco_ 前缀,并在 WebSocket 路径报错后切回 HTTP 由代理校正。该提交尚未进入任何 tag(最新 release v0.1.76 不含),0.1.77 hotfix 若早于该时间同样不含。

长度超限(ws_* / tco_* 84–85 字符 > 64):main 上目前没有任何针对 input[n].id 长度的归一化,这部分还没有修复。要定位落点,需要知道这些 item 在回放请求里的 type:ws_ 若是 web_search_call,OpenAI 输入契约对该类型的 id 是必填,不能像 function_call 那样直接省略 id,只能整条降级或改写;tco_ 不是 OpenAI 自身的 item 前缀,大概率是网关/LiteLLM 为工具输出生成的,处理方式同样取决于 type。

如果方便,请从 %APPDATA%\Cindy\codex-home\sessions\ 里找到 thread 01a08a53-… 的 rollout jsonl,把那几条超长 id 的 item 只保留 type / id / call_id 字段(去掉正文与参数)贴上来,再决定是在代理的跨供应商历史改写里降级这些 item,还是按类型重映射 id。

以上是源码对照,没有实机复现。

[Dante-dan]

我在当前 main 上继续核对后，确认这是两个相邻但不同的兼容性问题：#4129 已覆盖 fc_/ctc_ 前缀校正和 /responses/compact，但请求侧仍会原样保留超过 64 字符的 ws_/tco_ item ID；另外，WebSocket 返回长度校验错误时，现有会话级 HTTP 修复回退也不会被触发。

我准备按下面的最小范围处理：

1. 只对回放请求里的工具调用/工具结果 item ID 做稳定、保留类型前缀且不超过 64 字符的映射；不改 call_id、消息 ID、历史正文或已保存的原始会话。
2. 让明确的工具 item ID 长度错误复用现有的“该会话从 WebSocket 回退到 HTTP 修复路径”机制，不影响同进程的其他会话连接。
3. 用报告中的 84/85 字符样例构造 web_search_call / tool_call_output 回归，并覆盖 64 字符边界、相同开头不同结尾的碰撞规避、普通 /responses、/responses/compact、幂等性和请求不变性。

目前上述共享适配器回归 17/17、Desktop 主进程 loopback WebSocket→HTTP 集成回归 232/232，以及两个受影响包的 TypeScript 检查均已通过；仓库要求的 related-unit suite 仍在运行。这里的协议测试是平台无关的本机模拟，并非 Windows 实机验证；由于 issue 尚未提供脱敏 rollout，我也不会把构造的 item 类型写成对原会话的完整复现。

如果维护者没有更倾向的映射契约，我可以按这个范围完成提交并提 PR。

[sakiko-toyokawa]

补充独立复现证据（Windows，2026-09-20）：本地会话 c29098f3-7a43-416e-928d-788eaf2176fd 在同一任务内经历 x-ai-grok/grok-4.6 → gpt-5.6-luna 的路由切换。用户随后发送普通文本“我第一句话说的什么”，请求失败：[ApiIdParam] [input[59].id] [string_above_max_length] Invalid input[59].id: string too long. Expected a string with maximum length 64, but got a string with length 84 instead。关键日志：%APPDATA%\Cindy\logs\agent-2026-09-20.ndjson 记录 13041–13042；同一会话记录 currentProviderId=openai、model=gpt-5.6-luna，此前为 xd / x-ai-grok/grok-4.6。这支持 #4227 的判断：失败发生在历史 input 回放/跨 provider 适配阶段，而不是当前用户输入或上下文长度问题。该复现为 input[59]、长度 84，与 ws_* / tco_* 超长 ID 现象一致。错误后出现 OutputTextDelta without active item，应是上游拒绝后的流状态连带错误。数据库中可定位到该 session UUID；建议将普通 turn、model switch 后重试和 compact/retry 纳入回归。相邻的普通 message ID 前缀问题见 #4738。

[FicoHub]

@Dante-dan 你好，09-10 你表示准备按最小范围处理（工具 item ID 长度映射 + WS 长度错误触发 HTTP 回退），目前仓库里还没看到对应 PR；09-20 sakiko-toyokawa 又补了 Windows 下 grok → gpt-5.6-luna 的独立复现。请问是否仍在推进？如果方便的话回复一下进度或分支；若下一轮（约 2 小时后）仍无回音，我会在 #4752（msg/rs 前缀剔除，已合入）同一恢复规则框架上接手补一条针对 string_above_max_length 的 recovery rule，并在此登记，避免重复劳动。

[FicoHub]

接手：Dante-dan 09-10 表态后至今无 PR、上条询问无回音，我来处理（执行归属 #4227，基于当前 main）。若 Dante-dan 已有本地进展请随时说明，我会让位。

方案沿用 #4752 已合入的 codex-proxy 恢复规则框架，不改原生会话历史落盘：

1. 新增 recovery rule 匹配 Invalid 'input[N].id': string too long … maximum length 64（含 string_above_max_length 变体），重试时只改写顶层 input[] 中长度 > 64 的 id：保留类型前缀（ws_ / tco_ / fc_ 等），后接该原 id 的稳定 hash，总长 ≤ 64；同一原 id 在每轮回放中映射一致，call_id、正文与其他字段不动。
2. 同一 thread 后续请求经独立 activeStrip 预改写，避免每轮先撞 400；WS 内首次命中由既有 armCodexHttpRecovery 识别本规则、下一次 upgrade 回 426 落回 HTTP（覆盖「WS 返回长度错误不触发 HTTP 回退」）。
3. 回归：规则匹配/不匹配、改写长度与前缀、映射稳定、短 id 与非顶层字段不动、宿主注册与 WS 武装。

[FicoHub]

已开 PR：https://github.com/makecindy/cindy/pull/4783（0397498fc，基于 main ed4bef8）。实现、反证与验证见 PR 正文；真实 grok → gpt-5.6-luna 端到端与 compact 路径未在本机复现，已标注。