Codex Desktop: automation_update schema (root oneOf, type null) 400s on strict providers like DeepSeek (Responses API)
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
- #30132 — same error class on Azure (closed as completed, but Azure-only)
- #30523 — custom-provider behavior around
automation_update - #32873 —
automation_updateschema disagrees with backend - cc-switch#5447 — proxy-side oneOf flattening workaround for DeepSeek
1 Comment
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action