Add support for Azure DefaultAzureCredential authentication when using codex CLI with Azure Hosted Models

Workaround for now: Use Azure CLI to get a bearer token and set it as an environment variable.

     # Get Azure AD token and set as environment variable
     $env:AZURE_OPENAI_API_KEY = az account get-access-token --resource https://cognitiveservices.azure.com --query accessToken -o tsv

I have an implementation my team has been using for this feature here would love to continue the conversation. The implementation currently requires a config which looks like this:

  # Use a profile with: codex --profile azure-cli-chat

  [model_providers.azure-cli-chat]
  name = "Azure via CLI (Chat)"
  base_url = "https://YOUR_RESOURCE.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT"
  wire_api = "chat"
  query_params = { api-version = "2025-04-01-preview" }

  # Dynamic auth via Azure CLI (uses `az login` session).
  auth = { type = "azure_cli" }
  # Optional: scopes = ["https://cognitiveservices.azure.com/.default"]

  [profiles.azure-cli-chat]
  model = "gpt-5.1-codex"
  model_provider = "azure-cli-chat"

also happy to contribute this

Workaround for now: Use Azure CLI to get a bearer token and set it as an environment variable. # Get Azure AD token and set as environment variable $env:AZURE_OPENAI_API_KEY = az account get-access-token --resource https://cognitiveservices.azure.com --query accessToken -o tsv

In this way the token in always up to date or you have to send this command every time?

Solutions using env_key for the tokens need to be restarted whenever the tokens expire since env var are not updated in running processes.

Assuming your personal tokens have the right permissions for your Azure OpenAI resource, you can implemented a work around using a locally hosted proxy server.

Set up the config.toml like you would for Azure. Except the base_url is now http://127.0.0.1:8787/ (or whatever port you assign.) setting Env_key doesn't matter as the proxy will eat it. The proxy should route all paths and methods to the Azure endpoint. (Which would normally be in the base_url config field)

The proxy then uses DefaultAzureCrednetial() to get a valid token for cognitiveservices.azure.com and replaces the Authentication field in the header with this new bearer token.
The proxy server only requests a token at start up. Any time a request returns HTTP_UNAUTHORIZED, it assumes the token expired and requests a new one.

To get this to work, you may need to strip a couple other fields off the header which triggers some validation checks, like content-length.

I kept my proxy tiny as this is really just a crutch until there is better native support for Azure credentials.

Now you just start the server and enjoy the vibes.

---
I have model and model_reasoning_effort hard coded in the config.toml. With this set up, I have no model or reasoning selection. Anyone know how to provide model lists to Codex in VSCode using a custom model provider?

could someone be allowed to contribute this?

@niketansrane , please close as "Resolved". We can now use command-backed authentication as described here: https://developers.openai.com/codex/config-advanced#custom-model-providers (search for model_providers.proxy.auth).

For the next windows person
[model_providers.azure.auth]
command = "powershell"
args = ["-File", "C:\\FILE_LOCATION"]
timeout_ms = 5000
refresh_interval_ms = 300000

On macOS using codex-cli 0.125.0 with the following config.toml results in repeated attempts to authenticate via browser, but none of the authentication flows stick (browser pops, click on account, redirected, repeat):

[model_providers.azure.auth]
command = "/opt/homebrew/bin/az"
args = ["login"]
timeout_ms = 30000
refresh_interval_ms = 300000

Any guidance is appreciated. MS documentation says Entra ID is still not supported https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/codex

After messing around with a shell script, this appears to work properly (it double-prompts on first launching _codex_, but then you can use _codex_ with Foundry models as you would with envVar API Key approach):
config.toml

[model_providers.azure.auth]
command = "/path/to/azure-auth.sh"
#args = []
timeout_ms = 30000
refresh_interval_ms = 300000

azure-auth.sh

#!/bin/zsh

# Get Azure AD token and set as environment variable - uses the default/specified tenant
yes "" | /opt/homebrew/bin/az login --tenant ${YOUR_TENANT_ID} > /dev/null 2>&1
echo $(/opt/homebrew/bin/az account get-access-token --resource https://cognitiveservices.azure.com --query accessToken -o tsv)

hey guys,

Could we solve the Azure auth issue generically so it will be a fit for CLI, MCP-Server and any other ways which require integration with Azure auth?

We need to support of the following:

1) Developer credentials, so developers can authenticate when running locally.
2) Managed Identity and Workload Identity credentials.
3) Credential caching and renewal.
4) Other optional credential modes.

We can solve it in code by depending on the azure_core and azure_identity crates, we should be able to support most of this with minimal custom implementation, it will integrate smoothly with existing Codex auth model.

Unfortunately, we will not be able to benefit from the CLI authentication solution proposed in custom model providers. The main problem is that we run Codex as an MCP server and we need to use Workload Identity, which is not a CLI concern (there is no cli for workload identity, everybody will need to re-implement it).

I have a solution integrated with the latest codex, I'm looking forward to contributing into codex.

@etraut-openai , appreciate it if we can gain traction on this effort.

The browser loop happens because the auth command is running az login. That command is interactive and does not emit the bearer token Codex needs on stdout, so Codex keeps asking for auth instead of receiving a reusable token.

A safer shape is:

1. Run az login --tenant <tenant> once outside Codex.
2. Configure Codex auth to call a non-interactive script that only prints an access token.
3. Set refresh_interval_ms below the token lifetime.

Example script:

#!/usr/bin/env bash
set -euo pipefail
az account get-access-token \
  --resource https://cognitiveservices.azure.com \
  --query accessToken \
  -o tsv

Then point the provider auth command at that script. On Windows, the PowerShell version should do the same thing: no browser login inside the command, only az account get-access-token and print the token.

If the token command works but requests still fail, the next things to verify are the Azure OpenAI base_url deployment path, the api-version query param, and that the signed-in Azure principal has access to the specific Azure OpenAI resource.

Do not babysit people who don’t know how to read documentation.

This whole thread should have stopped when I posted this comment.

@cixtor ,

do you have a proposal how to deal with this using the custom model providers?