Describe the bug
Since yesterday (April 7, 2026), az vm create --no-wait fails with:
ERROR: Extra data: line 1 column 4 (char 3)
This is a JSON parsing error, most likely in the LRO continuation token handling introduced by the pickle-to-JSON migration in azure-core 1.38.0.
I can confirm that:
- Azure CLI 2.83.0+ (azure-core >=1.38.0) - fails
- Azure CLI 2.82.0 (azure-core 1.37.0) - works
(tested in GH CI environment, on default Ubuntu runner)
The continuation token format was changed from pickle to JSON in azure-core 1.38.0 (Azure/azure-sdk-for-python#44574). A follow-up PR added azure-asyncoperation header handling in azure-mgmt-core (Azure/azure-sdk-for-python#44658).
Related command
az vm create --resource-group $RG --name $VM --nics $NIC --image Ubuntu2404 \
--size Standard_D2s_v5 --admin-username azureuser --ssh-key-values key.pub \
--authentication-type ssh --no-wait
Errors
ERROR: Extra data: line 1 column 4 (char 3)
Issue script & Debug output
Expected behavior
Command works.
Environment Summary
Additional context
The same CLI version (2.84.0, pre-installed on GitHub Actions runner image) worked on April 2 and broke on April 7, pointing to a server-side change exposing the bug.
Pinning azure-cli to 2.82.0 (last version using azure-core 1.37.0) helped as a workaround.
Describe the bug
Since yesterday (April 7, 2026),
az vm create --no-waitfails with:This is a JSON parsing error, most likely in the LRO continuation token handling introduced by the pickle-to-JSON migration in
azure-core1.38.0.I can confirm that:
(tested in GH CI environment, on default Ubuntu runner)
The continuation token format was changed from pickle to JSON in
azure-core1.38.0 (Azure/azure-sdk-for-python#44574). A follow-up PR added azure-asyncoperation header handling in azure-mgmt-core (Azure/azure-sdk-for-python#44658).Related command
Errors
Issue script & Debug output
Expected behavior
Command works.
Environment Summary
Additional context
The same CLI version (2.84.0, pre-installed on GitHub Actions runner image) worked on April 2 and broke on April 7, pointing to a server-side change exposing the bug.
Pinning
azure-clito 2.82.0 (last version using azure-core 1.37.0) helped as a workaround.