[CLI][custom provider] Type-invalid item_ reasoning IDs survive replay validation and OpenAI expects rs_

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #38365

Powered by Codex Action

Thanks for the cross-reference. This is related to #38365 but not a duplicate.

#38365 requests a provider-neutral handoff/fork workflow and reports tool call/output ordering differences. This issue is a narrower request-serialization bug on the normal replay path:

• prepare_response_items_for_request() already attempts to sanitize invalid IDs;
• it uses the generic ResponseItemId::is_prefixed() predicate;
• item_foreign-reasoning therefore passes validation even though the concrete ResponseItem::Reasoning contract requires rs_;
• the next OpenAI request fails before any broader handoff normalization semantics are involved.

The bug has a bounded regression test and fix for both HTTP and WebSocket transports: validate against ResponseItem::id_prefix(), omit foreign reasoning/compaction items with type-invalid IDs from the request copy, and clear type-invalid IDs from portable items without mutating persisted prompt state.

The broader handoff design in #38365 remains valuable, but fixing this predicate prevents a deterministic API 400 in existing replay behavior.

The persisted cross-provider response-item ID failure here is a useful parser/diagnostic case for codex-rescue. The tool does not currently claim to repair arbitrary provider-specific item IDs or encrypted reasoning state; I’m interested in whether doctor handles the affected rollout conservatively without crashing or mutating it.

If you still have a synthetic or affected local session available, could you try:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

The valuable outcomes are either a bounded diagnostic finding or an explicit unsupported/unknown state—not guessing the intended ID and not replaying it.

Please share only sanitized output plus versions/exit codes. No raw rollouts/SQLite, encrypted provider state, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue

Thanks. I tested this conservatively on Windows 11 against two affected local rollouts, without sharing or modifying either source file.

Environment:

• Codex Desktop 26.810.7004.0
• Codex CLI source/runtime baseline 0.148.0-alpha.9
• codex-rescue 0.1.0a3, installed from audited source at commit d68027578ce1862510e57139ffddb09e6d09fe81
• upstream source tests: 66 passed, 1 skipped
• pip index versions codex-rescue did not find a published distribution in this environment, so I did not use an unverified package source

Sanitized results:

Case A:

exit code: 0
status: OVERSIZED_PAYLOAD
findings: OVERSIZED_PAYLOAD, UNKNOWN_OPERATIONAL_SCHEMA
valid records: 1534
recoverable prefix: true
oversized records: 3
unfinished tool calls: 0
compacted: true
operational events after compaction: 962
compaction state loss: false
unknown schema entries: 13 x mcp_tool_call_end
source SHA-256/size/mtime unchanged: true
stderr: empty

Case B:

exit code: 0
status: OVERSIZED_PAYLOAD
findings: OVERSIZED_PAYLOAD, UNKNOWN_OPERATIONAL_SCHEMA, UNFINISHED_TOOL_CALL
valid records: 128256
recoverable prefix: true
oversized records: 23
unfinished tool calls: 13
compacted: true
operational events after compaction: 99986
compaction state loss: false
source SHA-256/size/mtime unchanged: true
stderr: empty

The second report also classified newer Codex events conservatively: tool_search_call without a name (79), image_generation_call (1), mcp_tool_call_end (13), and web_search_call (35). It reported one bounded-memory correlation overflow and five outputs without matching calls.

So the useful result is: doctor did not crash, replay provider state, or mutate either rollout. However, 0.1.0a3 does not currently diagnose the type-specific response-item ID mismatch in this issue (item_... on a reasoning item that requires rs_...). Its UNKNOWN_OPERATIONAL_SCHEMA / UNFINISHED_TOOL_CALL findings also need to be interpreted cautiously for current Codex schemas; some are compatibility gaps rather than proof of rollout corruption.

No raw rollout, SQLite content, encrypted state, prompt, credential, thread ID, or private path was included in this test or comment.

Confirming your source-level analysis still holds on today's main @ 1f41cc5d92 — prepare_response_items_for_request is unchanged (core/src/client.rs#L943-L949), and ResponseItemId::is_prefixed still accepts any nonempty_nonempty shape (protocol/src/response_item_id.rs#L36-L39), so item_… survives exactly as you traced.

Two design notes for whoever implements the per-type check, both edge cases the obvious fix can trip on:

1. Provider-awareness cuts both ways. The strict per-type prefixes (rs_, msg_, fc_, …) are an OpenAI Responses API contract, not a wire-format universal — your scenario is custom-provider IDs replayed to OpenAI, but the mirror case (OpenAI rs_ IDs replayed to a permissive custom provider) is currently accepted and should stay that way. Scoping the strict validation to providers known to enforce it (or, more simply, validating against the expected-prefix table and clearing on mismatch regardless of provider — a cleared ID is safe everywhere) avoids breaking the lenient direction while fixing yours.

1. Clearing a reasoning item's ID is not always free. For plain-text reasoning items it just downgrades linkage, but reasoning replay with encrypted_content relies on the item's pairing with its adjacent items; if the strict check starts clearing IDs on valid rs_ items due to an over-broad table (or a future new prefix), replay quality degrades silently. Worth pairing the fix with a test that a well-formed OpenAI history round-trips with all IDs intact, alongside your foreign-ID rejection tests — the failure mode of an overzealous validator is quieter than the 400 you hit, which makes it easier to ship by accident.

Given you've already written the fix and regression tests, this issue looks like a strong candidate for the maintainers to invite a PR on per the contribution policy.

@SimpleZion

Thank you for the careful conservative test on 0.1.0a3 and for the precise gap report — both limitations you identified are addressed in the just-released 0.1.0-alpha.7.

1. Type-specific response-item ID mismatch (item_... on a reasoning item that requires rs_...): Alpha7 validates persisted response-item IDs against a per-type prefix table derived from the current upstream ResponseItem::id_prefix() values — reasoning → rs, message → msg, function_call → fc, custom_tool_call → ctc, etc. A prefixed but type-incompatible ID (exactly your item_-on-reasoning case) is now flagged as INVALID_PERSISTED_ITEM_ID. Legacy unprefixed IDs remain readable upstream and are deliberately not rejected, so this targets the replay-failure class without false-positiving old sessions.

1. UNKNOWN_OPERATIONAL_SCHEMA false positives on current schemas: mcp_tool_call_end, tool_search_call, web_search_call, and image_generation_call are now recognized known operational schema types, and a compatibility filter removes only explicit known-schema false positives from the results. So those 13 × mcp_tool_call_end, 79 × tool_search_call, 35 × web_search_call, and 1 × image_generation_call entries you saw should no longer be reported as unknown-schema corruption — they're compatibility gaps, as you correctly noted.

To re-run on your two affected rollouts (read-only, source untouched):

codex-rescue doctor <rollout-file>

Expected: the reasoning-item ID mismatch surfaces as INVALID_PERSISTED_ITEM_ID, and the current-schema event types no longer inflate UNKNOWN_OPERATIONAL_SCHEMA. If you still see a current Codex event type misclassified as unknown, the type name would be very useful so I can extend the table.

Your persisted-ID findings are now ported into the Rust adapter: type-aware ID prefixes, known/future operational schema handling, and bounded unfinished call/output correlation.

Migration update: active Codex Rescue development has moved to Vetto: https://github.com/shleder/vetto. The standalone shleder/codex-rescue repository remains public as compatibility history. User installation is now npm install --global @shleddy/vetto@next, with recovery under vetto rescue. The boundary remains read-only/copy-only and does not modify session JSONL or vendor SQLite. The newest diagnostic changes are merged into Vetto main and will be included in a later npm alpha; no source install is requested.