Expected an ID that begins with 'msg' — Codex
Quick fix
Create a new task and migrate the summary, or keep the old task on the Chat Completions conversion path; a permanent fix is still unverified.
Symptom
Section titled “Symptom”Invalid 'input[7].id': 'resp_..._msg'. Expected an ID that begins with 'msg'.CC Switch's Responses → Chat Completions conversion path synthesizes assistant message IDs beginning with `resp_`, such as `resp_*_msg`, which Codex then persists in the old task history. After switching to a native Responses provider with strict validation, Codex replays this ID in `input[]`. The native upstream requires message item IDs to begin with `msg_`, so it returns HTTP 400. Valid provider configurations and new tasks are unaffected by previously persisted history.
The issue remains open, with no official fix confirmed by the maintainers. The proposed permanent solution has two layers: make every conversion path generate `msg_*` IDs; and make the native Responses passthrough remove the `id` from old-history items whose `type="message"` and whose IDs do not begin with `msg_`. Later comments also report HTTP 404 errors caused by relay-synthesized reasoning IDs and another HTTP 400 caused by colons in tool-call IDs. These are related history-contamination variants, but they are not the error shown in this page's symptom.
To resume work immediately, create a new Codex task and migrate the old task's summary. The new task will not contain the persisted `resp_*_msg` item.
If you must keep the old task, continue using its original Chat Completions conversion path instead of switching it to a native Responses provider.
Wait for or test a build containing both layers of the fix: make the conversion layer consistently generate `msg_*` message IDs; and make the native Responses passthrough delete the `id` only from top-level `input[]` items whose `type="message"` and whose IDs do not begin with `msg_`, while preserving valid `msg_*` IDs and IDs on other item types. This solution remains a proposal in the issue, with no final validation result reported.
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 1 real issues
- Why do new tasks work while old tasks keep failing?
- The old task has stored the `resp_*_msg` ID generated by the conversion path and replays it when the task continues. A new task does not contain this contaminated history.
- Can changing the provider configuration or downgrading CC Switch fix the old task?
- No. Neither action repairs an invalid ID already written to the task history. As a workaround, create a new task and migrate the summary, or keep the old task on the Chat Completions conversion path.
- Is changing future message IDs to `msg_*` sufficient?
- No. That only prevents new history contamination. Existing old tasks still require invalid IDs to be removed from `type="message"` items before the native Responses passthrough.
- What should I do if a reasoning item returns HTTP 404 after cleaning `resp_*_msg`?
- Comments report that the native upstream may also treat relay-synthesized reasoning IDs as nonexistent stored items. This variant requires additional compatibility cleanup for reasoning items and cannot be fixed solely by correcting message IDs.
- Why can a colon in a tool-call ID also cause old-task replay to fail?
- Comments report that the strict upstream accepts only letters, digits, underscores, and hyphens. Synthesized IDs such as `fc_exec_command:0` contain a colon and therefore trigger a separate `invalid_value` error.
Related problems
Section titled “Related problems”This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.