Repository navigation
Codex Desktop: automation_update schema (root oneOf, type null) 400s on strict providers like DeepSeek (Responses API) #37786
Description
Summary
automation_update is emitted with a root-level oneOf JSON Schema and no top-level "type": "object" (type ends up null). OpenAI's own Responses endpoint tolerates this schema, but strict OpenAI-compatible providers that validate function schemas server-side reject every request that carries the codex_app tool namespace with a 400:
Invalid schema for function 'codex_app__automation_update': schema must be a JSON Schema of 'type: "object"', got 'type: null'
This is the same failure class as #30132 (Azure), which was closed as completed — but it still reproduces on the DeepSeek official integration (Responses API, wire_api = "responses", deepseek-v4-flash) on app version 26.803.41515 (current upstream ChatGPT.dmg).
Repro
- Configure DeepSeek per the official guide (
model_provider = "deepseek",base_url = "https://api.deepseek.com/",wire_api = "responses",model = "deepseek-v4-flash", plus the custommodels.jsoncatalog). - Start any thread in the ChatGPT/Codex desktop app.
- Requests that include
codex_app__automation_update(it is always eager-loaded —deferLoadingis explicitly removed for it) fail with the 400 above.
DeepSeek's strict JSON Schema validation documents supported keywords (enum, anyOf, ...) but rejects oneOf at the root; a schema whose top-level type is null is also rejected. The same schema works with OpenAI models because the OpenAI backend does not enforce this.
Suggested fix
Normalize automation_update's emitted schema so it is a valid object schema for strict validators:
- emit a top-level
"type": "object"(currentlynull), and/or - flatten the root
oneOfvariants into a mergedproperties/requiredobject when building the tool payload for non-OpenAI providers.
A runtime normalization (merge oneOf variants' properties, set type: "object") is sufficient and has been validated locally against DeepSeek.
Related
- json with "oneOf" as root causing error for azure openai endpoint #30132 — same error class on Azure (closed as completed, but Azure-only)
- Codex Desktop custom provider app/dynamic tools end turns without function_call after automation_update-related prompts #30523 — custom-provider behavior around
automation_update - Codex Desktop automation_update schema disagrees with backend (cwds vs projectId) #32873 —
automation_updateschema disagrees with backend - cc-switch#5447 — proxy-side oneOf flattening workaround for DeepSeek
Activity
github-actions commentedon Aug 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
wenlinl commentedon Sep 15, 2026
Additional root cause found on the current build (Desktop 26.818.61809 / CLI 0.149.0-alpha.4.3), DeepSeek Responses provider:
automation_updateis no longer eager-loaded here — it is deferred (deferLoading: true) and is not part of the initial tool manifest.The failure is now triggered by the built-in
tool_searchtool. When a search matches a deferred app/MCP tool, the next request carries that tool with an empty schema (parameters: {}), and the whole request is rejected with the same 400. After that the thread stays broken — every later turn fails before the model can answer (verified over ~6 consecutive turns in two threads).Minimal repro and payload matrix (namespace tool with
parameters: {}= exact error,parameters: nullor a real schema = accepted): #45585wenlinl commentedon Sep 15, 2026
Confirming the suggested fix from the other direction: adding a root
"type": "object"while leavingoneOf/$defsuntouched is sufficient. DeepSeek only validates the root type — nestedoneOf,$refand$defsare accepted as-is.Verified against
api.deepseek.com/responseswithdeepseek-v4-flash(Desktop26.818.61809/ CLI0.149.0-alpha.4.3):automation_updateschema as-is →400 got 'type: null'"type": "object"→200Same behaviour when the tool is reached through the deferred
tool_searchpath (details in #45585). So a one-line normalization on the client side is enough; no need to flatten theoneOfvariants.