Publish Bicep Modules to Private ACR does not apply Tags

[trindels]

Bicep version
run bicep --version via the Bicep CLI, az bicep version via the AZ CLI or via VS code by navigating to the extensions tab and searching for Bicep

Bicep CLI version 0.39.26 (1e90b06)

Describe the bug
A clear and concise description of what the bug is vs what you expected to happen

When publishing Bicep Modules to our private Azure Container Registry, the modules are successfully published. However, those modules are not properly tagged. Therefore, we cannot leverage those modules from our bicepparam files. We receive the message: "The artifact does not exist in the registry."

To Reproduce
Steps to reproduce the behavior:

1. Publish bicep module:

Using Powershell:

Publish-AzBicep Module -FilePath .\modules\bicepmodule.bicep -Target "br:[redacted]bicepsbox01.azurecr.io/bicep/modules/aihub/workspace:v0.2" -WithSource

Using CLI:

az bicep publish --file .\modules\bicepmodule.bicep --target "br:[redacted]bicepsbox01.azurecr.io/bicep/modules/aihub/workspace:v0.2"

2. Review bicep module in Container Registry (Azure portal -> Azure Container Registry -> Repositories). The Module appears in the list. However, if you click on the repository, it does not show any versions / tag history.

3. Attempt to import bicep using VSCode -- received error message.

Additional context
Add any other context about the problem here.

This worked on or around January 7, 2026.
This was not working after January 13, 2026.

[majastrz]

@trindels Is this still happening? Bicep relies on this functionality for its public modules as well and we're not getting any complaints from other users currently.

Also, is there anything special in your ACR configuration that could explain losing tags? Are you running any aggressive purge tasks, for example?

[trindels]

@majastrz - Yes, this is still happening. I tested this morning. It has been tested against two different ACRs. Both ACRs are newly deployed within the last 2 weeks, exactly to specifications in documentation. One of these ACRs is the one that was working on or around January 7.

[trindels]

@majastrz - Additionally, this problem is occurring on both my Windows development workstation AND from my ubuntu 24 ADO build agent.

[majastrz]

@trindels This is certainly an interesting one. I was not able to reproduce this with my own ACR. Whenever I publish a module, it's tagged like it's supposed to.

Can you enable tracing, retry the publish operation, and send me the logs? To enable tracing, set these environment vars before calling bicep publish:

BICEP_TRACING_VERBOSITY=full
BICEP_TRACING_ENABLED=true

(Any authorization info will be redacted in the logs, but the ACR name will not, so you might need to redact it manually before posting it.)

[trindels]

@majastrz Here is the trace that I performed.

trace.txt

[trindels]

@majastrz I found the problem. I had the quarantine policy enabled. I discovered this as the issue when I attempted to overwrite an existing version. The error message came back with the message that the original version was in quarantined status, not "already existing" which requires the --force command.

Then, I checked my ACRs and found that properties.policies.quarantinePolicy.status was set to "enabled". I changed property to "disabled". Now, my version publishing is working as expected.

I plan to study quarantining strategies for future implementations. However, that is a different topic.

My recommendation for Microsoft is to update this documentation to include a callout regarding the quarantinePolicy value just like the call out for azureADAuthenticationAsArmPolicy.

You may close out this reported issue.

[majastrz]

@trindels Thanks for the update. We will look into updating the docs to call this case out.