Codex Desktop: automation_update schema (root oneOf, type null) 400s on strict providers like DeepSeek (Responses API)

Open 💬 1 comment Opened Aug 10, 2026 by xjimlinx
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 18 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #36441

Powered by Codex Action