What variant of Codex are you using?
CLI
What feature would you like to see?
Request compression should support an explicit user-controlled mode, rather than only a conditional auto-enable path.
Today features.enable_request_compression = true sounds like "compress request bodies when this is enabled", but the actual behavior is narrower:
- compression is only used for Responses API requests
- only when using ChatGPT auth
- only when the provider is OpenAI
- otherwise the client silently falls back to no compression
That makes the config name misleading for operators. If I explicitly enable request compression in ~/.codex/config.toml, I expect it to either:
- force compression when possible, or
- fail loudly / log clearly when the request will not be compressed
A more explicit configuration model would be easier to reason about, for example:
request_compression = "off" | "auto" | "zstd"- or keep the current default behavior and add
force_request_compression = true
The current design behaves more like auto_if_supported_for_selected_auth_and_provider than enable_request_compression.
Additional information
Why this matters in practice:
- resumed / long-running threads can produce very large
/responses request bodies
- these bodies often contain large JSON structures, tool state, image references/base64, HTML, and encrypted reasoning payloads
- compression can be the difference between fitting through a proxy/gateway body limit or failing with
413 Payload Too Large
In a real session I measured, the serialized rollout was about 30.6 MB:
- raw: 30.6 MB
- gzip -6: 21.7 MB
- zstd -3: 10.6 MB
So this is not just a naming nit; it materially changes whether large resumed threads succeed.
I am not asking for the current default to change unconditionally. The request is to expose a configuration surface whose semantics match what operators expect:
off: never compressauto: current conservative behaviorzstd / force: always compress outgoing JSON request bodies for Responses API
If there are compatibility concerns for some providers or auth modes, a clear warning would still be much better than silently ignoring an explicitly enabled setting.
What variant of Codex are you using?
CLI
What feature would you like to see?
Request compression should support an explicit user-controlled mode, rather than only a conditional auto-enable path.
Today
features.enable_request_compression = truesounds like "compress request bodies when this is enabled", but the actual behavior is narrower:That makes the config name misleading for operators. If I explicitly enable request compression in
~/.codex/config.toml, I expect it to either:A more explicit configuration model would be easier to reason about, for example:
request_compression = "off" | "auto" | "zstd"force_request_compression = trueThe current design behaves more like
auto_if_supported_for_selected_auth_and_providerthanenable_request_compression.Additional information
Why this matters in practice:
/responsesrequest bodies413 Payload Too LargeIn a real session I measured, the serialized rollout was about 30.6 MB:
So this is not just a naming nit; it materially changes whether large resumed threads succeed.
I am not asking for the current default to change unconditionally. The request is to expose a configuration surface whose semantics match what operators expect:
off: never compressauto: current conservative behaviorzstd/force: always compress outgoing JSON request bodies for Responses APIIf there are compatibility concerns for some providers or auth modes, a clear warning would still be much better than silently ignoring an explicitly enabled setting.