Repository navigation
[Bug] v2.11.x forwards response_format to routed openai-chat providers, breaking auto-review under DeepSeek (400 'This response_format type is unavailable now') #1415
Description
Client or integration
Codex App
Area
Provider adapter
Summary
opencodex 2.11.0+ started forwarding response_format (including json_schema) to routed openai-chat providers in src/adapters/openai-chat.ts. The DeepSeek / Console Go upstream rejects json_schema with 400 "This response_format type is unavailable now". Codex's auto-review (approvals reviewer) always requests structured output, so every escalated tool call fails under deepseek. Version 2.10.2 did not forward response_format and worked fine.
Reproduction
- Run opencodex 2.11.0+ with
deepseek-v4-flashrouted via cliproxy (opencode-go upstream). - Trigger a Codex App auto-review (an escalated tool call needs approval).
- The reviewer request fails with the 400 below.
Normal (non-structured) requests succeed. Downgrading to 2.10.2 resolves it.
Version
2.11.1 (commit gc0a9db10f)
Operating system
macOS
Provider and model
cliproxy / deepseek-v4-flash (Console Go upstream)
Logs or error output
Provider error 400: {"error":{"param":null,"type":"invalid_request_error","code":"invalid_request_error","message":"Error from provider (Console Go): Upstream request failed: [invalid_request_error] This response_format type is unavailable now"}}Redacted configuration
{
"providers": {
"cliproxy": {
"adapter": "openai-chat",
"baseUrl": "http://127.0.0.1:8317/v1"
}
}
}Checks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
Note: related issue #1338 was auto-closed because it did not use the issue template; the underlying bug is not fixed.
Activity
Ingwannu commentedon Aug 10, 2026
Confirmed on current dev. src/adapters/openai-chat.ts:816-829 currently translates every internal textFormat request into response_format. Removing that translation globally would reintroduce the structured-output failure fixed by #1137 for providers that do support JSON mode or JSON Schema.
I will implement a narrow provider/model-scoped opt-out named noStructuredOutputModels. The default remains unchanged; only an explicitly listed native model id will omit response_format. The patch will not infer compatibility from a provider name or localhost URL and will not globally blacklist DeepSeek model names, because the same model id can sit behind a different upstream with structured-output support.
The regression coverage will verify both Responses and Chat Completions ingress, confirm the opted-out model omits response_format, and confirm a sibling model on the same provider still receives the original JSON Schema unchanged. I will also add config validation and the provider configuration reference.
Ingwannu commentedon Aug 10, 2026
Implemented the narrow compatibility path in draft PR #1424.
The patch keeps structured-output translation enabled by default and adds
noStructuredOutputModelsas an explicit provider/model-scoped opt-out. Only exact listed native model ids omitresponse_format; sibling models on the same provider continue receiving the original JSON Schema. It also adds persisted and management validation, PATCH normalization, configuration documentation, and regression coverage for both Responses and Chat Completions ingress.Verification on exact PR head
9c88233a37a99e0eb93dc1555dc2d522761f3184:origin/devbase9c051342d7ff7ad81b71911e359ad5935eaaf235I am leaving the issue open until the PR is independently reviewed and merged into
dev.Wibias commentedon Aug 11, 2026
Fixed by #1424