What the new flow does

OpenCode's Azure provider documentation now describes two routes. The older route accepts an Azure API key through /connect. The new route reuses an Azure CLI session:

1. Install the Azure CLI and run az login.
2. Run /connect in OpenCode, select Azure, then choose Microsoft Entra ID (Azure CLI).
3. Select an Azure resource visible to the active CLI session, or enter its name manually.
4. Choose a deployed model with /models.

When the signed-in identity has enough control-plane access, OpenCode lists resources, resource groups, and deployments. It refreshes inference access tokens through the Azure CLI, including CLI versions earlier than 2.54.0. The user signs in again after the CLI session expires.

The first implementation still required Bun somewhere along that path. Version 1.18.25 removed that dependency. Check the installed OpenCode version before treating an authentication error as an Azure permissions problem.

Keyless is not credentialless

An API key is normally a bearer secret. Someone who copies it may use the resource until the key is rotated or another control blocks the request. The key also reveals little about which employee or local session made a call.

An Entra login uses the developer's assigned identity and Azure role. Revocation and audit can follow an account, tenant, resource scope, and role instead of one key shared across a team.

The workstation still holds authentication material. Microsoft's Azure CLI authentication guide says a user login generates and stores a refresh token. OpenCode asks the CLI for access tokens and refreshes them while that session remains valid. The machine and its Azure CLI state still need protection.

Our Bandura credential review examined the same kind of boundary. Moving a secret out of one application does not finish the analysis. Follow the credential the application now relies on, which in this case is the Azure CLI session.

The active subscription can change the answer

One CLI session may span several tenants and subscriptions. OpenCode discovers resources from the active subscription. A successful az login therefore does not guarantee that the desired model appears.

Microsoft's subscription guide recommends inspecting the active context and switching it explicitly:

az account show --output table
az account list --output table
az account set --subscription "SUBSCRIPTION_NAME_OR_ID"

For a resource in another tenant, OpenCode's instructions use az login --tenant TENANT_ID. Set AZURE_RESOURCE_GROUP when the resource group is known and subscription-wide discovery is unnecessary. These settings determine which control plane OpenCode queries.

Model discovery and inference also have separate permission boundaries. An identity may be allowed to call a deployment without permission to list deployments. In that case, OpenCode keeps its Azure model catalog available. The selected model name still has to match the real deployment or be mapped explicitly in opencode.json.

Test the two permissions separately. A missing model in the picker may indicate missing discovery access, the wrong subscription, or a deployment-name mismatch. It does not by itself prove that the identity lacks inference permission.

Give the developer the role the agent needs

OpenCode tells Azure OpenAI users to assign Cognitive Services OpenAI User. For other Foundry models, it names Cognitive Services User. Microsoft's Azure AI role definitions describe Cognitive Services OpenAI User as a read and inference role. It can view models and deployments and create completion, embedding, image, audio, realtime, assistant, and response calls. Cognitive Services OpenAI Contributor can also write and delete deployments and policies.

An agent that only needs inference should not receive deployment-management rights because they simplify setup. Assign the narrower role at the resource scope where possible, verify inference, and add discovery access only if the workflow must list resources or deployments.

Our article on Agents Shipgate applied the authority-versus-capability distinction to pull requests. An agent's ability to perform an action is separate from whether its identity should be allowed to perform it.

Interactive work and automation are different

The new OpenCode path fits a developer already using az login on a local workstation. It inherits the person's MFA-backed session and Azure context.

Do not transfer that interactive pattern unchanged to CI or an unattended agent host. Microsoft says user identities used from command-line tools are subject to MFA. Workload identities such as service principals and managed identities are the intended alternative for automation. OpenCode's documented feature specifically reuses an Azure CLI user session; its release notes do not claim a new workload-identity setup for headless jobs.

For a local rollout:

• Install 1.18.25 or later and record the version.
• Confirm the expected tenant and subscription with az account show.
• Assign the inference role at the narrowest workable scope.
• Verify resource and model discovery separately from a real inference request.
• Sign out or clear the Azure CLI session and confirm that OpenCode loses access.

Organizations outside Azure RBAC may reasonably keep a provider key or use an OpenAI-compatible endpoint. OpenCode supports custom base URLs, so a multi-model service such as api.ish.chat can be configured without treating its API-key lifecycle as equivalent to Entra authentication.

OpenCode's change removes one long-lived provider key from the developer setup. The remaining boundary consists of the Azure identity, its role, the active subscription, and the refresh token held by the CLI. The team still has to configure and test each part.