OpenAI Codex Responses replay can emit oversized call_id from resumed cross-provider history

[louis030195]

Summary

I now have a concrete unit-test repro for the oversized input[*].call_id failure.

This is not a same-model replay case.
It is a cross-provider / cross-api resumed-history replay case:

• replay target: provider=openai-chatgpt, api=openai-codex-responses, model=gpt-5.4
• historical resumed assistant/toolResult messages: provider=screenpipe, api=openai-completions, model=gemini-3-pro

In this scenario, convertResponsesMessages(...) emits a function_call.call_id longer than 64 chars from real persisted session history, which matches the production OpenAI error:

Invalid 'input[...].call_id': string too long. Expected a string with maximum length 64

Minimal failing unit repro

Gist:

• https://gist.github.com/louis030195/1b924a10d9dbc9b5a7a434ac8dc0d46f

The gist contains:

• a single failing vitest unit test
• the exact command to run
• the failing assertion

Failing command

cd packages/ai && npx vitest --run test/openai-chatgpt-resume-call-id-repro.test.ts

Failing result

AssertionError: expected 930 to be less than or equal to 64

What the test proves

Given:

• a real historical tool call id captured from a resumed Screenpipe/pi session
• replay target model openai-chatgpt / openai-codex-responses / gpt-5.4

convertResponsesMessages(...) produces a function_call / function_call_output payload whose call_id exceeds the OpenAI Responses limit.

So the bug is reproducible locally at the message-conversion layer without needing Screenpipe runtime or a live provider call.

Important nuance

I am not claiming the fix is necessarily the normalization change I proposed earlier.
This issue is only to provide the concrete runnable repro you asked for.

If useful, I can follow up with a PR based on whichever fix direction you think is correct once alignment on expected behavior is clear.

[badlogic]

cheers, fixed in main.