Support custom model provider configuration for voice transcription

What variant of Codex are you using?

CLI (v0.106.0)

What feature would you like to see?

Enhancement request

Motivation

Voice transcription (spacebar hold-to-talk in TUI) currently always sends requests to the hardcoded OpenAI endpoint (https://api.openai.com/v1/audio/transcriptions) and unconditionally requires codex login (OpenAI auth). Users who configure a custom model provider via model_provider in config.toml — such as Azure OpenAI or self-hosted whisper-compatible services — cannot use voice transcription because it ignores the provider configuration entirely.

The main chat/completion path already respects model_provider settings (base_url, headers, query_params, api_key_env, etc.), so it is natural for voice transcription to do the same.

Current behavior

In codex-rs/tui/src/voice.rs:

1. resolve_auth() has no access to Config — it loads auth independently and always

requires a valid OpenAI token. Credentials from api_key_env, env_http_headers, or
experimental_bearer_token are ignored.

1. The transcription endpoint is hardcoded to https://api.openai.com/v1/audio/transcriptions.
2. Provider-specific http_headers, env_http_headers, and query_params (e.g. Azure's

?api-version=...) are never applied to the transcription request.

Proposed behavior

When a custom model_provider is configured, voice transcription should:

• Use model_provider.base_url + /audio/transcriptions as the endpoint
• Apply model_provider.http_headers and env_http_headers
• Append model_provider.query_params to the URL
• Use model_provider.api_key_env / experimental_bearer_token for auth, falling back to the OpenAI login token when available — mirroring the existing priority chain in auth_provider_from_auth(). Only require codex login when requires_openai_auth is true.

Limitations

This proposal reuses the existing model_provider configuration for voice transcription. The base_url and headers are shared, which is appropriate since they identify the same provider resource. However, query_params are also shared — if the chat and transcription endpoints require different query parameters (e.g. different api-version values on Azure), a dedicated configuration would be needed.

Additional information

_No response_