Azure Responses: second turn fails with 400 “message missing reasoning” error

What version of Codex is running?

codex --version → codex 0.0.0 (main @ c76528c)

What subscription do you have?

Azure

Which model were you using?

gpt-5-codex-medium served via Azure OpenAI Responses API deployment

What platform is your computer?

Darwin 25.1.0 arm64 arm

What issue are you seeing?

After configuring a Codex session to use an Azure OpenAI Responses endpoint, the very first user turn succeeds. When I send a second user message in the same session, Codex immediately returns:

    unexpected status 400 Bad Request: {
      "error": {
        "message": "Item 'msg_0c106b47ac8c42f100690e685738f88197b1b1bc75ce58e4a6' of type 'message' was provided without its required 'reasoning' item: 'rs_0c106b47ac8c42f100690e6857b1988197aba8adb5fa52d7d'",
        "type": "invalid_request_error",
        "param": "input",
        "code": null
      }
    }

This happens consistently; no additional tool calls or approvals are involved.

What steps can reproduce the bug?

1. Configure ~/.codex/config.toml to point at an Azure deployment (e.g., https://<resource>.openai.azure.com/openai) using the Responses API and run codex status to confirm the session shows the Azure model.
2. Start a new session (codex init or just launch the CLI) and send a first user message such as “Hello”. The assistant replies successfully.
3. Send a second user message (e.g., “Say goodbye”).
4. Observe the 400 error above; the turn aborts and the session becomes unusable for further input.

What is the expected behavior?

Subsequent user turns should succeed just like the first one—Codex should stream the next assistant response instead of receiving a 400.

Additional information

• Workaround: running codex resume <session-id> immediately after the failure lets me send one more message, but the next user message triggers the same 400 again.
• Hypothesis: When hitting Azure, Codex sets store: true and replays the previous turn’s msg_ item (see codex-rs/core/src/client.rs). Azure expects the corresponding reasoning item rs_ alongside that message. The CLI currently ignores the response.completed payload and only records incremental

response.output_item. events. Azure appears to send the reasoning block solely in response.completed, so Codex never stores it. On the next turn the replayed msg_ is missing its required reasoning partner and Azure rejects the request.

• Suggested fix direction: for Azure endpoints detected via provider.is_azure_responses_endpoint(), consume response.completed to backfill any reasoning items that weren’t seen incrementally (or otherwise ensure the reasoning item is persisted before replaying).