Subsequent calls fail with 400 after double interruption; error: “reasoning item without required following item”

Open 💬 16 comments Opened Oct 26, 2025 by nikhil-pandey

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

0.48.0

What subscription do you have?

Azure OpenAI

Which model were you using?

gpt-5-codex

What platform is your computer?

Linux 6.11.0-1018-azure x86_64 x86_64

What issue are you seeing?

After interrupting a conversation twice, all subsequent calls in the same conversation start failing with HTTP 400. Error payload:

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

This happens even when sending a simple follow-up user message; the server consistently returns the same 400 until the conversation is abandoned and a new one is created.

Context: I interrupted the same streamed response twice with “Conversation interrupted — tell the model what to do differently”, then continued the thread. I’m using Azure OpenAI.

What steps can reproduce the bug?

What is the expected behavior?

Interrupting an in-flight streamed response (even multiple times) should not corrupt conversation state.

Additional information

_No response_

View original on GitHub ↗

16 Comments

nikhil-pandey · 8 months ago

This has been happening quite often lately

voytas75 · 8 months ago

in my case the 400 starded today after updating to v0.52.0. first interaction with codex is OK the second ends with reconnecting and 400. restart helps.

Arthur742Ramos · 8 months ago

For me as well, issue appeared after updating to v0.52.0

voytas75 · 8 months ago

v0.53.0 - no 400 error - works seamless

nikhil-pandey · 8 months ago

This issue is occurring less frequently, but it has happened twice with me in the past few days with version 0.53.0. @etraut-openai

nikhil-pandey · 8 months ago

This issue still occurs in v0.57.0-alpha.3. To reproduce easily:

Send a message that triggers reasoning in the model.
Interrupt the model while it's reasoning.
After that, subsequent messages fail to process.

However, restarting and resuming the session seems to resolve the issue temporarily.

voytas75 · 8 months ago

@nikhil-pandey true - Today I came across this problem: canceling the request and re-query = 400.
Restarting helps.

geokal · 8 months ago

same here !!!! out of the blue

VS CODE:
Version: 1.106.2 (Universal)
Commit: 1e3c50d64110be466c0b4a45222e81d2c9352888
Date: 2025-11-19T16:56:50.023Z (18 hrs ago)
Electron: 37.7.0
ElectronBuildId: 12781156
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 22.6.0

codex extension
0.4.46

nikhil-pandey · 6 months ago

has been happening quite a lot lately

danielgwilson · 6 months ago

Still getting with Codex CLI v0.80.0

etraut-openai contributor · 6 months ago

I presume all of you are using the Azure-hosted OpenAI models? If you're seeing this error and are _not_ using the Azure endpoints, please let us know.

Are you using the "chat" or "responses" wire API in your model provider definition? If you're using the former, please switch to the latter. If you don't specify a "wire_api", Codex currently defaults to "chat". But we'll be removing support for "chat" at the end of the month.

tkellogg · 4 months ago

Alright, this is extremely frustrating because it's been happening for months and bug reports are repeatedly being closed with no acknowledgement, or even a good reason for why it should be closed.

I'm using responses. It's March, so clearly chat API isn't supported anyway (according to your previous message), and this still happens on a daily basis.

❯ codex --version
codex-cli 0.110.0

❯ cat ~/.codex/config.toml
model_provider = "azure"
profile = "gpt-52-xhigh"
disable_response_storage = true

request_max_retries    = 15    # HTTP retries
stream_max_retries     = 15   # SSE reconnects
stream_idle_timeout_ms = 600000

[profiles.gpt-52-xhigh]
model_provider = "azure"
model = "gpt-5.2"
model_reasoning_effort = "xhigh"

[model_providers.azure]
name = "Azure"
base_url = "https://....openai.azure.com/openai"
env_key = "AZURE_OPENAI_API_KEY"
# Newer versions appear to support the responses API, see https://github.com/openai/codex/pull/1321
query_params = { api-version = "2025-04-01-preview" }
wire_api = "responses"

tkellogg · 4 months ago

I just upgraded to gpt-5.3-codex xhigh and the problem is significantly worse. Codex is basically unusable.

FWIW I've found https://github.com/openclaw/openclaw/issues/1158 that seems potentially related. I changed from 2025-04-01-preview to v1 to no avail, it behaves the same.

etraut-openai contributor · 4 months ago

@tkellogg, have you reported this to Azure? I don't think we've heard of reports of this problem for OpenAI-hosted endpoints, which means that this is likely a problem that's specific to Azure's responses implementation or infrastructure. If you haven't reported it to them, they likely won't be aware of the issue.

tkellogg · 4 months ago

@etraut-openai no, i haven't. But I'm fairly sure it's the --search flag to blame. I pointed GPT-5.3-codex at codex's own code for the purpose of verifying this hunch, and the over-eager mofo fixed the bug. I haven't verified manually yet, but the diff isn't as big as I thought it would be and it looks plausible (it's on my gh fork): https://github.com/tkellogg/codex/commit/dcabb759b95d1b6995ac1f72188edb53aec7b799

In GPT's words:

The bug was in stream handling: we only persisted incremental response.output_item.* items, but Azure can put reasoning only in response.completed.response.output. That left replay history missing reasoning, so the next request could contain an orphan function_call and Azure returned the 400 (reasoning ... without required following item).

etraut-openai contributor · 4 months ago

@tkellogg, if your analysis is correct, then this appears to be an Azure bug. This limitation doesn't exist in the OpenAI responses implementation. As you might guess, we're reluctant to add Azure-specific work-arounds in the Code base. Please report the problem to Azure.