Codex Desktop 26.707 cannot continue session: UUID input item rejected; CLI resume works

What version of Codex CLI is running?

codex-cli 0.144.1

What subscription do you have?

ChatGPT subscription (exact tier not shown in this feedback flow)

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Darwin 25.5.0 arm64

What terminal emulator and version are you using (if applicable)?

Codex Desktop; Ghostty/zsh used only to verify CLI resume

Codex doctor report

Not collected for this Desktop reproduction; codex-cli can resume the same session successfully.

What issue are you seeing?

Codex Desktop 26.707.31428 cannot continue an existing local session, although the same session can be resumed and used successfully with codex-cli 0.144.1.

Desktop fails when submitting the next message with:

[ApiIdParam] [input[10].id] [invalid_id_prefix] Invalid 'input[10].id': '019f4c97-753c-7c21-8809-e282ac0043b1'. Expected an ID that begins with 'msg'.

The rejected UUID appears to be a locally generated history-item/message ID being replayed as a Responses API input ID. It is not the session ID. The Desktop path appears to preserve it, while CLI replay succeeds.

What steps can reproduce the bug?

Uploaded thread: 019f4e0e-e309-7d51-9a81-d651589ee864

What is the expected behavior?

Desktop should resume and continue the same local session successfully. Locally generated message IDs should either use the required msg_ prefix or be omitted before the Responses API request is sent. Desktop and CLI should replay the same session consistently.

Additional information

This appears to be a new Desktop-specific regression in the 26.707 release. Related reports with the same underlying validation failure:

• #20783 reports a locally generated UUID replayed as input[].id.
• #27928 reports locally generated review message IDs rejected because they do not begin with msg.
• #28814 introduced persisted response item IDs behind the item_ids feature.

On this machine, codex features list reports item_ids as under development and disabled for the CLI, which may explain why CLI replay succeeds while Desktop replay fails.

^{generated by a clanker}