[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')

[ShuaiHui]

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

1. Run opencodex 2.11.0+ with deepseek-v4-flash routed via cliproxy (opencode-go upstream).
2. Trigger a Codex App auto-review (an escalated tool call needs approval).
3. 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.

[Ingwannu]

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]

Implemented the narrow compatibility path in draft PR #1424.

The patch keeps structured-output translation enabled by default and adds noStructuredOutputModels as an explicit provider/model-scoped opt-out. Only exact listed native model ids omit response_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:

• focused tests: 138 pass, 0 fail
• typecheck: passed
• privacy scan: passed
• documentation build: passed, 221 pages
• full suite: 10,680 pass, 10 skip, 1 unrelated shim baseline failure; the same failure reproduces on exact origin/dev base 9c051342d7ff7ad81b71911e359ad5935eaaf235

I am leaving the issue open until the PR is independently reviewed and merged into dev.

[Wibias]

Fixed by #1424