Summary

When using the Codex/Responses integration path (api=openai-responses), the gateway can appear healthy/connected but produce no assistant output. Logs repeatedly show 400 status code (no body). This is commonly encountered when using third-party proxy/relay (Responses-compatible) endpoints.

Repro

1. Configure a provider/model with api=openai-responses and set it as default.
2. Restart the gateway.
3. Send any message (CLI or any channel).
4. Result: no reply; logs keep printing 400 status code (no body).

Notes (compatibility variance across Responses/Codex-compatible endpoints)

Some Responses-compatible endpoints enforce stricter request validation and may return 400 unless:

• instructions is present and non-empty
• input is an array/list
• stream=true is set

…and may reject unsupported fields such as:

• max_output_tokens

Requested fix

Add a configurable request normalization/compat layer for openai-responses, e.g.:

• ensure default non-empty instructions when missing
• optional forceInputArray / forceStream
• optional omit unsupported fields (e.g. max_output_tokens)

This should be part of stable configuration so users don’t need to re-patch runtime code after upgrades.

Keywords

openai-responses, Responses API, Codex, 400 no body, no output, silent failure, online but no reply, instructions, stream, input array, max_output_tokens, proxy, relay