Feature request: make request compression explicit instead of conditional behind enable_request_compression

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:

1. force compression when possible, or
2. 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 compress
• auto: current conservative behavior
• zstd / 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.