Feature Request: Support bicep as a key in requiredVersions in azure.yaml

[Roopan-Microsoft]

• Make sure you've installed the latest version using instructions

Output from azd version
azd version 1.23.13

Describe the bug
The requiredVersions property in azure.yaml currently only supports azd as a key. There is no way to declare a minimum Bicep CLI version requirement for a template. When a template uses Bicep features that require a specific Bicep version (e.g., >= 0.33.0), users with an older bicep version receive unclear compilation errors with no indication that the root cause is a Bicep version mismatch.

We request adding bicep as a supported key under requiredVersions so that azd can validate the bundled Bicep version against the template's requirement and surface a clear, actionable message to the user.

To Reproduce

1. Create a template that uses Bicep features requiring version >= 0.33.0 (e.g., AVM module references with newer syntax)
2. Remove the pre-compiled main.json
3. Use an older bicep version
4. Run azd provision or azd up
5. Observe: Bicep compilation errors with no mention of version mismatch

Expected behavior
azd should check the bundled Bicep version against a requiredVersions.bicep declaration in azure.yaml and display a clear message, for example:

ERROR: This template requires Bicep version >= 0.33.0, but your azd bundles version 0.26.54.
Please update bicep to the latest version: az bicep upgrade

Environment
Information on your environment:

• Language: Bicep 0.33.0+ (template requirement)
• IDE: Visual Studio Code 1.96+
• OS: Windows 11 / macOS / Linux (cross-platform issue)
• Template: multi-agent-custom-automation-engine-solution-accelerator

Additional context

• This affects multiple Foundry AI templates that use newer Bicep features (AVM modules, etc.)
• The requiredVersions.azd check already works well — extending the same pattern to bicep would be a natural addition.

[vhvb1989]

Hi @Roopan-Microsoft, thanks for filing this!

A few things to note:

1. azd already bundles Bicep 0.42.1, which is well above the 0.33.0 your template requires. Under normal circumstances, azd downloads and uses its own bundled copy — it does not rely on a system-installed bicep or az bicep.

2. The only way azd would use a different Bicep binary is if the environment variable AZD_BICEP_TOOL_PATH is set. When that env var is set, azd skips its bundled copy and uses the path specified. Could you check whether this variable is set in your environment?

   # Windows (PowerShell)
   echo $env:AZD_BICEP_TOOL_PATH
   
   # Linux/macOS
   echo $AZD_BICEP_TOOL_PATH
   

3. The error message you showed — "bicep is not recognized as an internal command" — strongly suggests azd is trying to invoke a bicep binary at a path that does not exist, which is consistent with AZD_BICEP_TOOL_PATH pointing to a missing or incorrect location.

4. To confirm exactly which bicep path azd is trying to use, could you please run your provisioning command with --debug and share the relevant output? For example:

   azd provision --debug
   

   In the debug output, look for a log line like using external bicep tool: <path> or the command invocation that includes the bicep binary path. That will tell us where azd is looking for Bicep.

Based on this, I don't think a requiredVersions.bicep feature is needed here — the issue is likely that azd is being directed to use a non-bundled Bicep binary via the environment variable. Let us know what you find!

[Roopan-Microsoft]

Thanks @vhvb1989 for your response. We will check and get back to you on this.

[Roopan-Microsoft]

Yes, you are correct — we are observing the same behavior on our end as well, and thank you for the guidance.

We have not seen this issue in the last two weeks across our GSAs reports, and we will continue monitoring closely. We will reach out if any further assistance is needed.

Thanks again for the support @vhvb1989

[microsoft-github-policy-service]

Hi @@Roopan-Microsoft. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[RickWinter]

Closing as this issue was already marked with issue-addressed. Please reopen or comment if further work is needed.