CLI /review follow-up fails with review_rollout_user id: Expected an ID that begins with 'msg'

What version of Codex CLI is running?

codex-cli 0.139.0

What subscription do you have?

Using an Azure OpenAI / Azure Foundry model provider.

Which model were you using?

gpt-5.5-1

What platform is your computer?

Darwin arm64 macOS 26.5.1

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

Ghostty 1.3.1, zsh

Codex doctor report

Not pasting the full report because it contains local paths and provider-specific resource names.

Relevant redacted excerpts:

{
  "overallStatus": "ok",
  "codexVersion": "0.139.0",
  "config.load": {
    "model provider": "azure",
    "model": "gpt-5.5-1"
  },
  "network.websocket_reachability": {
    "model provider": "azure",
    "provider name": "Azure OpenAI",
    "wire API": "responses",
    "supports websockets": "false"
  },
  "updates.status": {
    "latest version": "0.139.0",
    "version status": "current version is not older"
  }
}

What issue are you seeing?

Running /review can leave the session in a state where the next Codex request fails with a Responses API validation error:

{
  "error": {
    "message": "Invalid 'input[0].id': 'review_rollout_user'. Expected an ID that begins with 'msg'.",
    "type": "invalid_request_error",
    "param": "input[0].id",
    "code": "invalid_value"
  }
}

This appears related to the older /review issues that were closed after fixing the colon-containing id (review:rollout:user) in #9360 / #9131, and to #9860 which reported the same review_rollout_user / Expected an ID that begins with 'msg' error. The current failure is still reproducible on the latest published CLI version, 0.139.0.

From inspecting the current source, /review still materializes local message ids named review_rollout_user / review_rollout_assistant, and attach_item_ids later reattaches stored item ids into serialized Responses API message items. That means a local client-generated message id can be sent back as input[].id, while the API expects message ids to be server-generated ids beginning with msg.

A similar root cause is described in the still-open hook issue #20783, where a local UUID message id is sent back to the Responses API and rejected with the same Expected an ID that begins with 'msg' validation rule.

What steps can reproduce the bug?

1. Configure Codex CLI 0.139.0 with an Azure OpenAI / Azure Foundry provider using the responses wire API.
2. Open a repository.
3. Run /review.
4. After the review finishes, continue in the same session with a follow-up prompt.
5. The next request can fail immediately with the validation error above.

What is the expected behavior?

The /review command should be able to roll its result back into the parent session and allow follow-up prompts without sending local client-generated message ids as Responses API input[].id values.

Additional information

The previous fix in #9387 appears to have addressed the older Azure validation failure caused by colons in review:rollout:user, but the current validation rule rejects review_rollout_user because message item ids are expected to begin with msg.

A minimal fix might be to preserve id for non-message Responses API output item types, but only reattach message.id when it looks like a server-generated message id, for example when it starts with msg. Locally generated message ids such as review_rollout_user, review_rollout_assistant, and UUIDs should not be serialized as Responses API message ids.