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

Open 💬 2 comments Opened Aug 18, 2026 by JayZhu03
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 10 days ago

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

  • #38855

Powered by Codex Action

JayZhu03 · 10 days ago

Update from my side

After I reported this, the old task briefly started working again and accepted one follow-up message. I thought the problem might have been fixed, but the very next follow-up failed with the same input[322].id error.

This makes the situation worse because the task can look healthy for one turn and then fail again. Restarting and reopening it do not make the recovery permanent. I have now seen this happen in more than one long-running task.

For me, this is not just a failed request. These tasks contain weeks of engineering context: design decisions, business definitions, investigation results, and the reasons behind code changes. When the task stops accepting messages, the history is still visible but I cannot continue using it. I have to start over in a new task and explain everything again.

Please treat this as a history-replay problem. I need Codex to skip or repair the invalid historical ID while keeping the rest of the conversation, rather than forcing me to abandon the task.