json with "oneOf" as root causing error for azure openai endpoint

I've also had this same issue with version 26.623.12021

This is quite serious, we aren't able to use codex any longer @jif-oai @cconger @anp-oai

Also having the issue on 26.623.31921

Easy to reproduce. I'm a CLI user/don't use automations myself so excuse the clunky usage. Once a thread triggers the automation it's completely dead. Forking prior to the call does restore functionality.

Break the thread

<img width="811" height="1872" alt="Image" src="https://github.com/user-attachments/assets/6aed9197-01ec-4e28-a1fc-e884c7df9f87" />

Fork to Restore

<img width="814" height="1329" alt="Image" src="https://github.com/user-attachments/assets/8b8ebc90-abda-414a-a9cb-048ea76ddf6f" />

This appears to be caused by an out-of-date deployment of code in Azure. The Azure team regularly updates their code to match OpenAI's, but sometimes they lag in their deployment. This problem will likely resolve itself once they redeploy. If you haven't already done so, please report to the folks at Azure. That may help accelerate a fix.

There should at least be a warning when updating or fallback code - its quite disruptive and we're caught offguard

Still ongoing

For those who are affected and can't wait for them to fix this issue - download an older version here https://github.com/nooblyf/codex-releases/releases/tag/2026-06-12

This appears to be caused by an out-of-date deployment of code in Azure. The Azure team regularly updates their code to match OpenAI's, but sometimes they lag in their deployment. This problem will likely resolve itself once they redeploy. If you haven't already done so, please report to the folks at Azure. That may help accelerate a fix.

@etraut-openai It worked before with older versions of codex (see comment above, 2026-06-12 is fine). Is there any reason why a fallback can't be added to this codebase so that threads don't get "bricked" in the event of an outdated API?

need fix

On 26.623.81905, with Azure OpenAI provider.

Sharing from the AOAI/Foundry side at Microsoft, the problem's been root-caused and a fix is rolling out ASAP.

As @etraut-openai described, this stemmed from a recent (last few weeks) extension of Responses API non-strict schema support not yet being fully reflected in AOAI's configuration.

We're following up to see how we can better coordinate to catch these issues sooner. It's a particularly tricky class of problems: extended schema component support within schema payload is a lot more subtle than new, typed properties on an API, and that makes it tough for both defensively handling it (in Codex) as well as comprehensively anticipating it (in 1-to-1 AOAI support). Tricky or not, though, it's important.

On 26.623.81905, with Azure OpenAI provider.

same here.

same 。trace

I am broken. I am helpless. I am exhausted. I am silent

guys the issue still exists, whats going on? using gpt 5.6 sol via azure

For those who are affected and can't wait for them to fix this issue - download an older version here https://github.com/nooblyf/codex-releases/releases/tag/2026-06-12

Quoting my reply for those who just scrolled to the end. Older releases still work.

Confirmed this is still failing on July 15, 2026, and reproduced it directly against Azure's Responses API (so this is not just a Codex client/thread issue).

Environment:

• Codex Desktop: 26.707.72221
• Azure AI Services resource: East US, S0
• Deployment: gpt-5.6-sol / GlobalStandard (model version 2026-07-09)
• Endpoint: POST /openai/v1/responses, Entra bearer auth

Minimal result:

• Function parameters with a top-level oneOf -> HTTP 400: Invalid schema for function 'automation_update_repro': schema must be a JSON Schema of 'type: "object"', got 'type: "None"'.
• The same request changed to a top-level {"type":"object", ...} -> HTTP 200.

Failing request IDs for Microsoft to trace:

• x-request-id: 116b61d6-f9d8-9de2-86c9-194a8ee7dcb6
• apim-request-id: 2ddfab1f-841c-4ac4-9080-9a0d8b38fabd
• Region header: East US
• Timestamp: 2026-07-15 07:00:45 UTC

So the rollout mentioned on July 1 either has not reached this East US path/current model stack, or this has regressed. A local proxy that rewrites top-level oneOf into an object schema unblocks Codex, but users should not need that workaround.

@trrwilson could the Azure team check the request IDs / rollout status? Please keep this issue open until the direct API reproduction succeeds without schema rewriting.

@Ahmet-Dedeler Thanks for your feedback, this is indeed failing again on gpt-5.6-sol. I'm working with azure team on this!

@Ahmet-Dedeler gpt-56-sol is fixed. Let me know if you're still seeing other issues