Codex CLI: Support any Azure OpenAI-compatible endpoint (custom DNS, Bearer & api-key auth, OAuth/refresh token support; parity with standard Python SDKs)

What feature would you like to see?

Description:
Codex CLI currently recognizes Azure OpenAI endpoints only if their hostname contains select hardcoded Azure substrings, and only supports api-key authentication. This ignores enterprise-standard OAuth flows where the api-key is actually a time-limited token, acquired by exchanging a refresh token with an authorization server (per OAuth2/spec).
Azure OpenAI is frequently deployed behind custom domains, API gateways, and access patterns where both api-key and Authorization: Bearer (OAuth2) tokens are valid and standardized. Azure’s SDKs, including LangChain’s AzureChatOpenAI, support these deployments natively.

Current Limitation in Codex:

• Hostname marker check blocks valid Azure deployments under custom gateways.
• No support for OAuth2 flows: cannot supply a refresh token or auth server URL in config; cannot have Codex CLI automatically fetch and rotate tokens, or use Bearer authentication.
• Only static api-key headers supported, which is not always secure or viable in production.
• Enterprises must manually acquire and update tokens, severely limiting secure/automated use-cases.

Suggested Enhancement:

• Allow endpoints to opt into Azure compatibility regardless of domain/marker.
• In config.toml, support (just like Python SDKs):
• api-key as before (for static/testing use)
• authorization_server_url (OAuth2 token endpoint)
• refresh_token (or client credentials) for dynamic token acquisition/rotation
• Option to use Bearer token via Authorization: Bearer
• Support both static and auto-refresh mechanisms:
• If api-key is present, use as header.
• If refresh_token and authorization_server_url are present, handle OAuth exchange and inject token, as in standard enterprise Azure OpenAI SDKs.
• Document both flows and provide robust error messaging.

Standard Practice / What Competitor SDKs Do:

• AzureChatOpenAI in LangChain (see Python/JS, and reference in docs) accepts any domain, supports both api-key and Bearer tokens, and works with tokens dynamically acquired through OAuth/OIDC.[^1][^2]
• Azure/Microsoft’s own Rust SDK crates (e.g., azure_identity, inth_oauth2_azure) and unofficial ones like async-openai support flexible auth and dynamic tokens.[^3][^4]
• OAuth (Bearer token) is encouraged by Azure for secure production environments instead of static keys.

Config.toml (suggested new fields):

model = "<model>"
model_provider = "azure"

[model_providers.azure]
name = "Azure"
base_url = "https://<enterprise-endpoint>/openai/deployments/<model>/chat/completions"
query_params = { api-version = "<version>" }
wire_api = "responses"
env_http_headers = { "api-key" = "AZURE_OPENAI_API_KEY" }
refresh_token = "<refresh_token>"                  # new
authorization_server_url = "<auth_server_url>"     # new

If provided, Codex should use OAuth2 to exchange the refresh_token with authorization_server_url for a Bearer token, then inject as Authorization: Bearer <token>.
If omitted, fall back to api-key as today.

References:

• Python: AzureChatOpenAI dynamic auth
• Rust: azure_identity, inth_oauth2_azure

Benefit:

• Codex CLI will match Azure standards and modern SDKs for secure, automated, and enterprise deployments.
• Unblocks secure zero-trust automation and compliance needs in major organizations.

Are you interested in implementing this feature?

Yes, I am interested in this feature as it will directly benefit my enterprise workflow and enable secure integration with Azure OpenAI deployments.
I will wait for the maintainers to acknowledge and discuss before attempting any implementation or PR.

Additional information

_No response_