Azure Developer CLI 1.34.2 Adds Extension Dependency Checks, Layers and Windows Named-Pipe Auth

The roundup also says the releases include security improvements and asks users to upgrade. It names no CVE and describes no specific vulnerability, so treat it as general hardening, not a security advisory.

The release timeline​

The GitHub release records fill in dates that the monthly post leaves out. According to the 1.34.2 release page, 1.34.2 is dated 2026-09-23. A Dependabot bump in a community extension repository shows 1.34.1 dated 2026-09-16. That same 1.34.1 changelog lists a fix for a shutdown panic when telemetry is disabled, along with an Azure Container Registry log-streaming fix. The roundup describes both of those in broader terms.

The monthly post covers all four versions. Not every change below shipped in 1.34.2, and the roundup doesn't give a version for most items. This article doesn't guess.

Summary: Four releases landed in September. 1.34.1 and 1.34.2 shipped on September 16 and 23. Assume the full feature list needs the latest build.

Extension management gets a real dependency model​

Extensions became central to azd over the summer. Microsoft's August roundup reported that the extension framework is generally available. Once you have a package ecosystem, uninstalling things gets harder. September adds a dependency model:

• azd extension uninstall now tracks ownership. The 1.34.2 notes say the command records why each extension was installed, blocks removing extensions other extensions depend on unless --force is used, and offers to remove dependencies that are no longer needed unless --no-dependencies is set.
• azd extension show explains the dependency tree. It now displays compatibility, ownership, dependencies, and installed dependents. The JSON output now uses camelCase keys and omits empty fields. Scripts that parse the old JSON may need small changes.
• Version-compatible installs. Install, update, init and automatic-install flows now choose extension releases that are compatible with the running azd version.
• Safer bundle downloads. Extension bundle installs now follow redirects, and azd warns you if an HTTPS download redirects to plain HTTP.
• Startup reliability. A fix addresses intermittent extension startup timeouts caused by concurrent initialization.

In practice, this is what apt autoremove does, applied to your developer toolchain. You can clean up leftovers without silently breaking an extension that relied on them.

For extension authors: versioned contracts and a principal API​

Microsoft now ships stable and preview versioned gRPC contracts. Authors can build against the stable API surface, or opt into preview APIs, while existing extensions keep working. The preview contract adds a useful call. The 1.34.2 notes describe it as Account.GetCurrentPrincipal to the preview extension gRPC contract so extensions can read the current identity's object ID and principal type without decoding access tokens.

Anyone who has pulled an oid claim out of a JWT will see why that's better. Microsoft's own Foundry extensions are already relying on it. According to the GitHub release list, the azd-ext-azure-ai-projects 1.0.0-beta.13 pre-release (September 30) has a breaking change that requires azd 1.34.2 or later for host-based Foundry principal resolution. It also fixes provisioning principal resolution for guest users and service principals. If you use the Foundry projects extension, upgrading the core CLI is now required.
Summary: Uninstalls now respect dependencies, extension show explains what depends on what, and extension authors get versioned APIs. The latest Foundry projects extension beta won't do host-based principal resolution on anything older than 1.34.2.

Project structure: layers and bounded parallelism​

The roundup says azure.yaml now supports top-level infrastructure and service layers, so complex projects can organize provisioning and deployment. This builds on layered provisioning, which has been growing for months. The May/June release added safer dependency analysis and an explicit dependsOn field in azure.yaml. In August, layered provisioning infers Bicep dependencies.

Microsoft Learn's layered-provisioning page gives the details, and some of them should shape how you use it:

• Layered provisioning is still labeled beta.
• Layers go under infra with a required name and path. Optional properties are module, provider (Bicep or Terraform) and dependsOn.
• If you define infra.layers, you can't also set root-level path, module or deploymentStacks under infra. That configuration moves into each layer.
• For Bicep and custom or extension providers, azd infers ordering by scanning *.bicepparam and *.parameters.json files. Terraform, Pulumi and ARM layers don't expose their inputs to that inference, so you need an explicit dependsOn.
• azd provision <layer> and azd down <layer> target a single layer. azd down with no argument tears layers down in reverse dependency order.
• Watch out: if several layers deploy into the same resource group and you use the default resource-group deletion behavior, azd down can delete shared resources. Learn suggests turning on deployment stacks with azd config set alpha.deployment.stacks on so layers are tracked independently.
• You can't use --preview when provisioning several layers at once. Name a layer instead.

A short layered setup based on Learn's examples looks like this:

infra:
  layers:
    - name: networking
      path: ./infra/networking
    - name: application
      path: ./infra/application
      dependsOn:
        - networking

Those limits come from the current documentation. Not all of them are new in September.

Per-phase concurrency limits are the other structural change. You can now set how much work runs in parallel during the package, provision, publish and deploy phases. The roundup gives no setting names, defaults or numeric ranges, so check the azure.yaml schema reference before you configure this. The use case is easy to picture: a monorepo with a dozen services, where unlimited parallel container builds swamp a build agent or hit registry throttling. A related fix isolates intermediate artifacts when .NET services publish concurrently "on supported .NET SDKs". The roundup doesn't list which SDK versions count.

Another fix keeps environment templates when project mappings are saved and restored.

Summary: Layers now organize both infrastructure and services, and you can cap parallelism per phase. Layered provisioning is still beta, and shared resource groups plus azd down can remove more than you intended.

Authentication and template safety​

• External auth over local IPC. External authentication hosts can connect through Unix domain sockets or Windows named pipes when you set AZD_AUTH_ENDPOINT. This matters for Windows shops that broker credentials through a local host process. The roundup doesn't document endpoint syntax or security requirements, so check the official docs before you wire this into production.
• Managed identity fix. The 1.34.2 notes fix login details for system-assigned managed identities being reported as not logged in. That's good news for anyone running azd on Azure-hosted build agents.
• Archived template warning. azd init --template now warns you when the template repository is archived, so you can cancel before cloning something unmaintained. It's a warning only; archived templates aren't blocked.

Deployment and container build fixes​

This section may matter most to anyone who has watched a remote build fail with no useful output:

• Project-level predeploy and postdeploy hook output now shows up during azd up. Thanks Jon Gallant (@jongio) for the contribution!
• ACR log streaming recovers when a remote build replaces or truncates its log.
• If ACR refuses to schedule a remote task, azd falls back to a local container build. Make sure the machine can actually build containers, for example with Docker Desktop on Windows, or this fallback won't help you.
• ACR remote-build failures now produce stable, structured diagnostics, and the build logs are kept.
• Service condition values are honored before azd initializes or checks disabled services.
• Quota errors from unrelated resource providers now get resource-specific guidance, not Microsoft Foundry recovery steps.
• Invalid YAML in azure.yaml returns a clear validation error; it no longer crashes. The fix was contributed by @Siglud.

Agent detection, telemetry and housekeeping​

azd has been detecting AI coding agents so it can switch to non-interactive mode. The July roundup said it now auto-detects CI/CD and AI-agent environments to run non-interactively. September tightens that heuristic. Terminals that inherit stale agent markers stay interactive. Empty markers are ignored. Active Codex and Cursor sessions take priority, and the Cursor desktop app itself is no longer treated as an agent. If azd stopped prompting you in a normal terminal for no obvious reason, this is probably the fix.

Other changes:

• The agentic azd init flow now reports AI credits in place of premium requests.
• Telemetry's execution.environment field reports agency inside Agency sessions. Ambient OpenTelemetry resource attributes are no longer exported, though declared fields remain.
• Homebrew casks now use Homebrew's declarative postflight_steps.
• Bundled tools were updated to Bicep CLI v0.47.16 and GitHub CLI v2.101.0.

What Windows developers should do​

1. Check your version with azd version. You want 1.34.2 or newer, especially if you use the Foundry AI projects extension.
2. Upgrade using your install method. Microsoft's April roundup said azd update graduates to public preview, so you can update with a single command on any platform. The GitHub record for 1.34.2 also lists a Windows x64 MSI and ZIP, plus a Windows ARM64 ZIP marked alpha. On Snapdragon machines, be aware of that support status.
3. Audit extensions with azd extension show before you uninstall anything, and update any scripts that parse its JSON for the camelCase keys.
4. Review layered projects that share resource groups before you run azd down, and consider deployment stacks.
5. Try concurrency limits if parallel deploys have been overloading your build agents, using the schema reference for the exact keys.

Also new in September: docs and templates​

Microsoft Learn added or updated guides for building, exploring, extending and starting azd templates (September 16), plus a guide to choosing a container build and deployment workflow (September 15). The template gallery gained a large set of LangGraph hosted-agent templates from the Microsoft Foundry team. They cover basic chat, deep research agents, Foundry Toolbox integrations, human-in-the-loop approval, observability with Application Insights, and resilient long-running agents, over both the Responses and Invocations protocols.

Bottom line​

This isn't a flashy month for azd, and that's fine. The fixes are the kind that stop a Friday deploy from turning into a long night: dependencies you can't accidentally break, parallelism you can cap, clearer ACR failures, and agent detection that stops misreading your terminal. Just remember that layered provisioning is still beta, and that "security improvements" with no CVE attached is a reason to upgrade, not a threat to respond to.