Repository navigation
az cognitiveservices account show returns networkInjections as null on an injected Foundry account #33808
Description
Describe the bug
az cognitiveservices account show returns networkInjections: null for a Foundry (AIServices) account that does have network injection configured. The property is present and correct when the same resource is read via az rest at API version 2025-04-01-preview.
This is a false negative on a property that cannot be changed after account creation. Tooling that checks whether an existing account is network-injected — before deciding whether to deploy into it — will conclude "not injected" and may proceed against the wrong account. The remediation for a genuine mismatch is provisioning a new account and migrating, so a silent wrong answer here is expensive.
To Reproduce
Given a Foundry account created with:
properties: {
networkInjections: [
{
scenario: 'agent'
subnetArmId: '<subnet delegated to Microsoft.App/environments>'
useMicrosoftManagedNetwork: false
}
]
}CLI:
az cognitiveservices account show -n <name> -g <rg> \
--query "properties.networkInjections"Output:
null
Raw REST, same resource:
az rest --method get --uri \
"https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.CognitiveServices/accounts/<name>?api-version=2025-04-01-preview" \
--query "properties.networkInjections"Output:
{
"scenario": "agent",
"subnetArmId": ".../virtualNetworks/<vnet>/subnets/agent-subnet",
"useMicrosoftManagedNetwork": false
}Expected behavior
az cognitiveservices account show returns networkInjections when the account has it, or documents that the command reads an API version which omits the property.
Likely cause
The cognitiveservices command module appears to pin an API version predating networkInjections, so the field is dropped during deserialisation rather than surfaced as unknown.
Environment
- azure-cli 2.77.0
- Resource:
Microsoft.CognitiveServices/accounts,kind: AIServices - Region:
eastus2 - Confirmed working via REST at
2025-04-01-preview
Impact / workaround
Workaround is to bypass the CLI convenience command and use az rest with an explicit API version. That works, but it is easy to get wrong: the natural command returns a confident, incorrect answer rather than an error, so nothing signals that the result is unreliable.
Activity
azure-client-tools-bot-prd commentedon Jul 28, 2026
Hi arush-saxena,
2.77.0 is not the latest Azure CLI(2.88.0).
If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.
yonzhan commentedon Jul 28, 2026
Thank you for opening this issue, we will look into it.
arush-saxena commentedon Jul 29, 2026
Closing — this does not reproduce on 2.88.0. My report was against a stale CLI and I should have verified before filing. Apologies for the noise.
Re-tested against a live network-injected Foundry account (
kind: AIServices,eastus2, capability hostSucceeded) on azure-cli 2.88.0:Ground truth via REST (
2025-04-01-preview):[ { "scenario": "agent", "subnetArmId": ".../virtualNetworks/vnet-accel-iso/subnets/agent-subnet", "useMicrosoftManagedNetwork": false } ]az cognitiveservices account show --query "properties.networkInjections"on 2.88.0:[ { "scenario": "agent", "subnetArmId": ".../virtualNetworks/vnet-accel-iso/subnets/agent-subnet", "useMicrosoftManagedNetwork": false } ]Identical. The
nullI originally reported was on 2.77.0, which predates the fix.Thanks to @azure-client-tools-bot-prd for catching the version immediately — that was the right call and it saved maintainer time.
For anyone who lands here from a search: if
networkInjectionsreads asnullon an account you believe is injected, checkaz versionfirst. Since network injection cannot be changed after account creation, a false negative here is expensive — it can lead you to deploy into the wrong account, where the remediation is a new account plus a migration rather than a config change.