[Codex Desktop] Existing tasks become unusable after legacy tool ID replay

What happened

I have run into this problem more than once in Codex Desktop on Windows. A long-running task works normally for a while, and then a follow-up message suddenly fails with an API validation error:

Invalid 'input[322].id': 'srvtoolu_<redacted>'. Expected an ID that begins with 'ws'.

The rejected item is an old web-search/tool item in the task history. The task is not empty or deleted; it simply cannot process another message because an old ID is being sent back in a format that the current API no longer accepts.

In the latest case, the task briefly appeared to recover and accepted one follow-up message. It failed again on the next message with the same error. Restarting Codex and reopening the task do not reliably help.

How I encountered it

1. I used Codex Desktop for a long-running engineering task with web search and other tool calls.
2. The task accumulated a large amount of design discussion, investigation results, and implementation context.
3. After the task had been kept across an application or protocol update, I reopened it and sent another message.
4. Codex replayed the old history and the request failed because one historical input[].id did not have the prefix expected for its item type.

The same class of failure has happened in multiple tasks, not just one conversation.

Why this is a serious problem

I use long-running Codex tasks as working sessions for real engineering work. They contain decisions, domain explanations, investigation results, file context, and the reasoning behind previous changes. When a task becomes unusable, I cannot simply resend the last prompt and continue.

The transcript may still exist, but I cannot reliably use the context stored in it. I have to create a new task and manually reconstruct the important decisions and background. Repeating that work costs a lot of time and model usage, and some context is inevitably lost. Since this has happened more than once, it feels like the session memory is being lost repeatedly.

Expected behavior

When Codex replays an old task, it should validate historical IDs against the concrete input-item type and remove or migrate IDs that are no longer valid. The repair should keep the user messages, assistant responses, tool outputs, and the rest of the usable conversation context.

I need a way to continue an existing task without abandoning it and rebuilding the context in a new task.

Related reports include #38855, #32282, #34283, #27928, and #32198.

Start by reproducing the failure in Codex Desktop on Windows with a long-running task containing an old web-search item, then trace replay of the task history and validation of input[].id. Done means an existing task with legacy IDs can accept follow-up messages while preserving its usable user, assistant, and tool history.