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

Open 💬 2 comments Opened Jul 10, 2026 by mariusvniekerk

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.

<sup>generated by a clanker</sup>

View original on GitHub ↗

2 Comments

null0526 · 1 month ago

I can reproduce the same issue in Codex Desktop on Windows.

[ApiIdParam] [input[3].id] [invalid_id_prefix] Invalid 'input[3].id': '019f5655-ab96-72e2-81f8-0b303322b894'. Expected an ID that begins with 'msg'.

The rejected value is a locally generated UUID rather than a server-generated msg... message ID.

Environment:

Product: Codex Desktop
Platform: Windows x64
Authentication: ChatGPT subscription
App version: not captured yet
Failure occurs when submitting a message in an existing session

This appears to confirm that the regression is not macOS-specific. Codex Desktop is replaying a local history-item ID as a Responses API input[].id.

A robust fix would be to omit locally generated IDs from serialized ResponseItem::Message objects and only attach message IDs that are known server-generated msg... IDs.

jjoanna2-debug · 1 month ago

Same here on Codex Desktop for macOS. An existing session now fails on every new message with the same invalid_id_prefix pattern:

[ApiIdParam] [input[0].id] [invalid_id_prefix] Invalid 'input[0].id': '019f5e75-1dcd-70a3-94f9-cc1aeec62ecd'. Expected an ID that begins with 'msg'.

On another attempt, the identical UUID was rejected at input[367].id, so this appears to be the same local-history ID being replayed at different positions in the request payload. The failure occurs in the macOS app and is also reflected in the iOS remote view of that same Mac-hosted session.

@etraut-openai, is there any update on the fix or an expected release? The affected thread is currently unusable in Codex Desktop.