Repository navigation
Top-level query functions aren't parsed correctly #32320
Description
Activity
- addedbugThis issue requires a change to an existing behavior in the product in order to be resolved.This issue requires a change to an existing behavior in the product in order to be resolved.
on Oct 24, 2025 azure-client-tools-bot-prd commented
on Oct 24, 2025 More actionsHi Josiah Vinson (@jovinson-ms),
2.77.0 is not the latest Azure CLI(2.78.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.
- addedAuto-AssignAuto assign by botAuto assign by botARMaz resource/group/lock/tag/deployment/policy/managementapp/account management-groupaz resource/group/lock/tag/deployment/policy/managementapp/account management-group
on Oct 24, 2025 - addedAzure CLI TeamThe command of the issue is owned by Azure CLI teamThe command of the issue is owned by Azure CLI teamquestionThe issue doesn't require a change to the product in order to be resolved. Most issues start as thatThe issue doesn't require a change to the product in order to be resolved. Most issues start as that
on Oct 24, 2025 Thank you for opening this issue, we will look into it.
Here are some similar issues that might help you. Please check if they can solve your problem.
- az cli incorrect parsing of query "--query "[0].keys(@)" #14972
- "az network vnet peering list": Unexpected whitespace significance in query parameter #11497
- JMESPath error when getting a boards query result count #16232
Possible solution (Extracted from existing issue, might be incorrect; please verify carefully)
Solution 1:
This is a Windows PowerShell issue. We have documented it at https://github.com/Azure/azure-cli/blob/dev/doc/use_cli_effectively.md#argument-parsing-issue-in-powershell. To workaround it, please insert
--%afterazto force PowerShell to treat the remaining characters in the line as a literal.Reference:
Solution 2:
At least now I have an idea why the variant with the extra space
az vm list --query "[0].keys(@) "worked. I assumed any character would do, but the real difference seems to be that the whitespace prevents PowerShell from stripping the quotes. This is confirmed by the fact that the following variants of the command work as expected (in PowerShell):az vm list --query " [0].keys(@)"az vm list --query "[0].keys( @ )"Reference:
Solution 3:
We updated our doc: https://github.com/Azure/azure-cli/blob/dev/doc/use_cli_effectively.md#quoting-issues
Reference:
Powered by issue-sentinel
- removedbugThis issue requires a change to an existing behavior in the product in order to be resolved.This issue requires a change to an existing behavior in the product in order to be resolved.
on Oct 25, 2025
Describe the bug
When a command includes a
--queryflag with a top-level function, the last character of the query isn't evaluated.Example:
If I include at least one extra space (or
=) in the query, things work:Related command
This seems to be a core issue - I've found the same results with three different provider commands.
Errors
Issue script & Debug output
The
--debugflag doesn't work because of the parsing issue:Expected behavior
I expect top-level query functions to work without whitespace padding.
Environment Summary
azure-cli 2.77.0 *
core 2.77.0 *
telemetry 1.1.0
Extensions:
account 0.2.5
application-insights 1.2.2
azure-devops 1.0.2
fzf 1.0.2
healthcareapis 1.0.1
load 1.1.1
providerhub 1.0.0b2
resource-graph 2.1.0
Dependencies:
msal 1.34.0b1
azure-mgmt-resource 23.3.0
Python location 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe'
Config directory 'C:\Users\jovinson.azure'
Extensions directory 'C:\Users\jovinson.azure\cliextensions'
Python (Windows) 3.13.7 (tags/v3.13.7:bcee1c3, Aug 14 2025, 14:15:11) [MSC v.1944 64 bit (AMD64)]
Additional context
No response