Missing required fields in Responses API input items when using non-Azure endpoints

Resolved 💬 2 comments Opened Feb 19, 2026 by zhuangqh Closed Feb 25, 2026

What version of Codex CLI is running?

0.104.0

What subscription do you have?

gptoss

Which model were you using?

gptoss

What platform is your computer?

Darwin 25.3.0 arm64 arm

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

warp

What issue are you seeing?

Bug Description

When Codex sends a multi-turn conversation to a custom/OSS Responses API endpoint
(e.g., vLLM), several required fields are omitted from input items. The same
requests work against the official OpenAI endpoint, which appears to silently
tolerate the missing fields — but any strictly-conforming server will reject them
with a 400 validation error.

Root Cause

In codex-rs/codex-api/src/endpoint/responses.rs, attach_item_ids is guarded
by an Azure-only condition:

if request.store && self.session.provider().is_azure_responses_endpoint() {
    attach_item_ids(&mut body, &request.input);
}

This means id fields are only patched back onto items when targeting an Azure
endpoint. For the default OpenAI endpoint and all OSS endpoints (e.g., vLLM, any
OpenAI-compatible server), the serialization relies on
#[serde(skip_serializing)] on the id field of ResponseItem::Reasoning in
protocol/src/models.rs — and attach_item_ids is never called to restore it.

Additionally, ResponseOutputMessage and ResponseInputMessageItem items sent
in conversation history are missing fields that the OpenAI spec marks as
Required.

Missing fields per item type

| Item type | Role | Missing field | OpenAI spec requirement |
|-------------|-------------------|---------------|---------------------------------------------------------------|
| reasoning | — | id | Required[str] |
| message | assistant | status | Required[Literal["in_progress", "completed", "incomplete"]] |
| message | user / system | id | Required[str] |

What steps can reproduce the bug?

Reproduction

  1. Deploy any OpenAI-compatible Responses API server (e.g., gptoss deployed on vLLM)
  2. Configure Codex to use it: base_url = "http://localhost:8000/v1"
  3. Start a conversation that produces reasoning output or spans multiple turns
  4. On the second turn the request payload will be missing the fields above,

causing the server to return:

400 Bad Request
{
  "error": {
    "message": "N validation errors: {'type': 'string_type', 'loc': ('body', 'input', ..., 'str'), ...}"
  }
}

What is the expected behavior?

Expected Behavior

All input items sent to any Responses API endpoint should include the fields
required by the
OpenAI Responses API spec,
regardless of whether the target is Azure, the official OpenAI endpoint, or a
third-party compatible server.

Additional information

Proposed Fix

Remove the is_azure_responses_endpoint() guard so attach_item_ids runs for
all endpoints:

// codex-rs/codex-api/src/endpoint/responses.rs

// Before
if request.store && self.session.provider().is_azure_responses_endpoint() {
    attach_item_ids(&mut body, &request.input);
}

// After
attach_item_ids(&mut body, &request.input);

Additionally, ensure status: "completed" is always populated on assistant
message items and id is always populated on user/system message items before
serialization.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗