[Haerbin23456]

背景

Responses API 的 ACP round 2 会为 assistant message 重映射 ID。原实现将 msg-proxy-${round}- 直接拼到上游 ID 前；当 Codex 返回 54 字符的 message ID 时，重映射结果为 66 字符，超过 Responses input item 的 64 字符限制。客户端下一轮回放该 ID 后会持续收到 400。

Closes #242

修改

• 使用现有的 hashId() 对上游 message ID（缺失时使用 output index）生成 16 位确定性哈希。
• 保留 msg-proxy-${round}- 前缀，最终常规 ID 长度从 66 降为 28。
• 将真实的 54 字符 Codex message ID 加入 round-2 生命周期回归测试。
• 断言重映射 ID 不超过 64 字符，并继续验证 output_item.added、文本 delta、content part、output_item.done 引用一致。

验证

• npm run typecheck：通过
• npm run build：通过
• node --import tsx --test tests/responses-round2-lifecycle.test.ts：通过
• 负向验证：临时恢复旧拼接逻辑后，新增断言精确报错 got 66；恢复本补丁后通过
• npm test：593 项中 591 项通过；上述回归测试通过。另 2 项为本机 Windows 环境既有失败：系统代理使预期的 direct 变为 windows-system，以及临时目录清理偶发 EPERM，均不涉及本次修改路径

GitHub CI

• Ubuntu / Windows、Node 22 / 24 四组测试矩阵均通过
• version-guard 通过
• build-artifact 在发布 npm PR 包时失败：fork PR 无法读取上游 npm secret，日志显示 NODE_AUTH_TOKEN 为空并报 ENEEDAUTH；编译阶段本身已通过

[ranxianglei]

Model: qwen3.8-27b (vllm)

Reviewed — the core fix is correct and clean. Reusing the existing hashId() (sha256-16hex) is better than minting a new digest: deterministic, 64-bit collision space, one less new API. Lifecycle references stay consistent through the shared remapped map, and the 54-char fixture + <= 64 assertion covers the regression nicely. (The build-artifact ENEEDAUTH failure is the known fork-PR limitation — npm secrets are invisible to forks — not a code issue.)

One real gap: this prevents new over-long ids but does not heal already-poisoned rollouts. The exact scenario from #242 — a Codex rollout that persisted a 66-char msg-proxy-2-… id and now 400s on every turn — still stays dead, because the poisoned id lives client-side and gets replayed as input[].id before the adapter ever runs. --passthrough doesn't help either.

I had opened #244 with the same root-cause fix plus an ingress healing step: sanitizeResponsesInputIds() in prepareResponses rewrites any input[].id longer than 64 chars to a short deterministic id before the request goes upstream, so a rollout that is currently 400-ing recovers by itself on the next request. Two ways forward, either is fine:

1. I push that healing commit onto this branch (maintainer edits enabled) and we close #244 as superseded, or
2. This merges as-is and I rebase #244 down to healing-only.

Preference: option 1 — one PR, full fix, your authorship on the root-cause commit.

[ranxianglei]

Model: qwen3.8-27b (vllm)

Added the ingress-healing commit (30b3324) to this branch as discussed in the review, adapted to reuse your hashId() choice for consistency:

• sanitizeResponsesInputIds() export in src/loop/adapter-responses.ts — rewrites any input[].id longer than 64 chars to msg-fix-<hashId> (deterministic, idempotent, call_id untouched)
• prepareResponses (src/server.ts) calls it before the projection reads the input, so a rollout that is currently 400-ing on every turn recovers on its next request — no client-side cleanup needed
• New unit test in tests/responses-round2-lifecycle.test.ts; devlog entry added

Verified on this branch: typecheck ✅, 594/594 ✅, build ✅. #244 closed as superseded — the root-cause fix credit stays with this PR.