Fix invalid input[].id values containing colons during /review

[makserik]

What version of Codex is running?

codex-cli 0.86.0

What subscription do you have?

Running gpt-5.2-codex 2026-01-14 on Microsoft Foundry

Which model were you using?

gpt-5.2-codex

What platform is your computer?

Darwin 24.5.0 arm64 arm

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

zsh

What issue are you seeing?

Running /review in Codex CLI after reviewing a PR against main fails with an API validation error.

Full error message (PII redacted):

{
  "error": {
    "message": "Invalid 'input[3].id': 'review:rollout:user'. Expected an ID that contains letters, numbers, underscores, or dashes, but this value contained additional characters.",
    "type": "invalid_request_error",
    "param": "input[3].id",
    "code": "invalid_value"
  }
}

The error indicates that Codex CLI is sending an input[].id containing colons (:), which are rejected by the OpenAI API validator.

What steps can reproduce the bug?

1. Open a repository with an open pull request targeting main
2. Run Codex CLI
3. Execute /review to review the PR
4. The initial review seems to work
5. Try to ask follow up questions.
6. Codex CLI constructs a multi-input request to the OpenAI API
7. The request fails with an invalid_request_error due to an invalid input[].idObserved invalid ID value:

review:rollout:user

No custom configuration or non-default options are required to reproduce this.

Session ID, token usage, and context window usage were not exposed by the CLI at the time of failure.

What is the expected behavior?

What is the expected behavior?

Codex CLI should generate API-compatible input[].id values.

Internally generated IDs should only contain characters allowed by the OpenAI API:

[a-zA-Z0-9_-]

The /review command should complete successfully without failing API validation.

Additional information

1. This appears to be a client-side ID formatting issue rather than a user configuration problem.
2. The failure occurs with standard /review usage.
3. A simple normalization step (e.g. replacing non-allowed characters with _ or -) would likely resolve the issue.
4. Happy to test a fix or provide additional logs if needed.

[etraut-openai]

Thanks for the bug report. I'm guessing that this problem is specific to the Azure endpoint. We haven't heard of any similar reports for OpenAI-hosted models.

We should be able to work around the Azure limitation. I have a PR that's up for review.

[etraut-openai]

This should be fixed in the next release.