[FEATURE]: Add an explicit config option to force Codex-compatible request formatting #18203

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Description

Currently, whether LLM.stream() uses Codex-compatible formatting is determined implicitly by this logic:

const isCodex = provider.id === "openai" && auth?.type === "oauth"

This works for the common case, but it becomes problematic in some deployment scenarios.

Use case

A user may be connecting OpenCode to a Codex forwarding endpoint.
In this case, the client needs to send requests in Codex-compatible format, for example:

• omit the regular system prompt
• pass prompt content through the instructions field
• adjust other request fields as needed

At the moment, the only workaround is to place an additional HTTP proxy between OpenCode and the forwarding endpoint, so that the proxy can rewrite the request into the expected format.
This is workable, but not ideal and adds unnecessary complexity.

Current limitation

The current behavior depends entirely on provider/auth inference, which means:

• some forwarding endpoints may receive the wrong request format
• users cannot explicitly control whether Codex formatting is used
• using plugins/hooks is not a clean solution here, especially because there is no easy hook to remove max_output_tokens

Proposal

Introduce a new CFG configuration option that allows users to explicitly control whether Codex-compatible formatting should be used.

Suggested behavior

• null / unset: keep the current automatic detection behavior
• true: force Codex-compatible formatting
• false: force standard formatting

Default

The default should remain null or false to minimize impact on existing users and preserve current behavior unless explicitly configured.

Expected benefits

• supports Codex forwarding/proxy setups
• supports custom user-owned gateways
• gives users explicit control with minimal breaking changes

I believe this is a fairly common built-in scenario that many users may need. Any feedback, suggestions, or concerns are very welcome — please feel free to reply anytime.