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

1. Configure DeepSeek per the official guide (model_provider = "deepseek", base_url = "https://api.deepseek.com/", wire_api = "responses", model = "deepseek-v4-flash", plus the custom models.json catalog).
2. Start any thread in the ChatGPT/Codex desktop app.
3. Requests that include codex_app__automation_update (it is always eager-loaded — deferLoading is 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" (currently null), and/or
• flatten the root oneOf variants into a merged properties/required object 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_update schema disagrees with backend
• cc-switch#5447 — proxy-side oneOf flattening workaround for DeepSeek

Start at the automation_update tool payload generation used by the Responses API and inspect how its root oneOf schema is emitted for non-OpenAI providers. Reproduce the 400 with the DeepSeek configuration described above, then verify that requests no longer fail and OpenAI behavior remains intact.