Skip to content

New 2.91.0 cask version is being flagged by macOS Gatekeeper #34192

Closed
Closed
New 2.91.0 cask version is being flagged by macOS Gatekeeper#34192
Assignees
naga-nandyala
Labels
Azure CLI TeamThe command of the issue is owned by Azure CLI teambugThis issue requires a change to an existing behavior in the product in order to be resolved.customer-reportedIssues that are reported by GitHub users external to the Azure organization.
Milestone
Backlog

Description

@squerble
squerble
opened on Oct 8, 2026

Describe the bug

macOS v26.7.1
Latest homebrew
Updated to azure-cli v2.91.0 this morning.

Since the update, every .so file found under /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/ is being flagged by macOS Gatekeeper. I am unable to clear the com.apple.provenance and com.apple.quarantine flags with sudo xattr on the directory or files directly. I was able to get around this by running sudo xattr -d com.apple.quarantine $(find /opt/homebrew/Caskroom/azure-cli/2.91.0/ -name "*.so") but this seems a bit inadvisable for regular users. This is interfering massively with management of our corporate AKS clusters with tools like k9s.

I am also unable to allow these files via System Settings > Privacy & Security. I allow them as each error appears, but the next time az is run they are flagged again, and I'm not sure allowing them is even actually allowing them.

Apologies if this report is a bit scarce, I don't usually do this and not sure what other info you may need to help.

Related command

Any az or other apps that would call az (such as k9s when attaching to AKS clusters)

Errors

The standard macOS popup about not allowing user to open files as it hasn't been deemed safe by Apple.

Image

Issue script & Debug output

Not sure how I can output script as it's macOS interfering.

Expected behavior

To not have files quarantined.

Environment Summary

az --version
azure-cli                         2.91.0

core                              2.91.0
telemetry                          1.1.0

Extensions:
alb                                2.0.1

Dependencies:
msal                              1.39.0
azure-mgmt-resource               24.0.0

Python location '/opt/homebrew/opt/python@3.14/bin/python3.14'
Config directory '/Users/user/.azure'
Extensions directory '/Users/user/.azure/cliextensions'

Python (Darwin) 3.14.8 (main, Sep 30 2026, 17:55:09) [Clang 21.0.0 (clang-2100.3.34.2)]

Legal docs and information: aka.ms/AzureCliLegal


Your CLI is up-to-date.

Additional context

No response

Activity

  1. squerble
    added
    bugThis issue requires a change to an existing behavior in the product in order to be resolved.
    on Oct 8, 2026
  2. microsoft-github-policy-service
    added
    customer-reportedIssues that are reported by GitHub users external to the Azure organization.
    on Oct 8, 2026

  3. yonzhan commented on Oct 8, 2026

    @yonzhan
    Yong Zhang (yonzhan)
    on Oct 8, 2026
    Collaborator

    Thank you for opening this issue, we will look into it.

  4. Abdul-Karim-Baisuev commented on Oct 8, 2026

    @Abdul-Karim-Baisuev
    ABDUL-KARIM BAISUEV (Abdul-Karim-Baisuev)
    on Oct 8, 2026

    Thank you for opening this issue, we will look into it.

  5. x-engineering-agent commented on Oct 8, 2026

    @x-engineering-agent
    x-engineering-agentbot
    on Oct 8, 2026 – with X Engineering Agent
    Contributor

    Bug Analysis

    Affected area: macOS distribution and Homebrew cask packaging in Azure/azure-cli, not an AKS command implementation or the installed alb extension.

    Reported behavior: After upgrading to Azure CLI 2.91.0 on macOS 26.7.1, Gatekeeper repeatedly rejects native .so files inside the cask's Python 3.14 environment. The reporter supplied the CLI/Python versions, installation paths, the recurring OS dialog, and the resulting impact on applications that invoke az. This is sufficient to investigate the packaging/launch path; the report has not been independently reproduced and the signing/notarization cause is not yet established.

    Implementation requirements:

    • Start from dev and inspect the macOS artifact assembly, signing/notarization, and Homebrew distribution paths, including repository-owned release/CI scripts. Compare the affected cask with its last working distribution before choosing a source change.
    • Correct the verified packaging defect within the repository's supported source scope. Preserve signing, notarization, Gatekeeper, and package integrity protections; do not disable security checks or strip security attributes as the fix.
    • Add focused regression coverage for the identified artifact/signing failure, and require authorized macOS packaging validation against an ordinarily downloaded/quarantined artifact. Cover clean installation and upgrade, native-module loading, and normal CLI startup without bypasses. Do not substitute command-module unit tests for macOS artifact evidence.
    • Keep the change limited to packaging and directly related documentation/tests. If resolution requires release credentials, artifact re-signing, an external cask change, or protected pipeline changes outside the permitted source scope, report that precise maintainer-owned dependency rather than weakening policy or claiming a code-only fix.

    PR title & description format (required)

    This repo enforces a PR format (guide). Please author the PR exactly as follows or CI's Check the Format of Pull Request Title and Content will fail.

    Use this EXACT PR title (copy verbatim, do not reword):

    [Packaging] Fix #34192: `az`: Fix macOS Gatekeeper rejection of the Homebrew cask

    Keep the backticks around the command and the Fix #34192: prefix. You may only adjust the wording after the command (the final summary) if the fix changes; the [Packaging] prefix, issue link, and backticked command must stay.

    Description — follow the PR template and fill in:

    • Link the issue — start the Description with a closing keyword so the PR auto-links and closes it: Fixes #34192.
    • Related command — the az ... command this affects.
    • Description (mandatory) — why the bug happens, what you changed, and the resulting behavior.
    • Testing Guide — example command(s) showing the fix works.
    • History Notes — leave the title to drive the history note, or add extra lines in the same format (component in brackets + the command in backticks), e.g. [Packaging] `az <command>`: <note>.
    • Keep the template checklist and tick the items you've satisfied.

    Posted by x-engineering-agent (Fixer)

  6. Yong Zhang (yonzhan)
    assigned
    Naga Nandyala (naga-nandyala)
    on Oct 8, 2026
  7. Yong Zhang (yonzhan)
    added
    Azure CLI TeamThe command of the issue is owned by Azure CLI team
    on Oct 8, 2026
  8. Yong Zhang (yonzhan)
    added this to the Backlog milestone on Oct 8, 2026

  9. x-engineering-agent commented on Oct 8, 2026

    @x-engineering-agent
    x-engineering-agentbot
    on Oct 8, 2026 – with X Engineering Agent
    Contributor

    Implementation Result

    No pull request was opened because the implementation run completed without a validated code change.

    The source analysis remains available above. A maintainer should confirm whether the issue is already resolved on the current target branch or provide the reproduction or root-cause evidence needed for another implementation request.

    Posted by x-engineering-agent (Fixer)

  10. naga-nandyala commented on Oct 8, 2026

    @naga-nandyala
    Naga Nandyala (naga-nandyala)
    on Oct 8, 2026
    Contributor

    Hi squerble,

    TL;DR: All native binaries inside the Homebrew Cask archive are signed by Microsoft and notarized by Apple. We could not reproduce the Gatekeeper warnings with a clean installation, so could you please try the steps below and let us know the results?

    Thank you for reporting this. We verified the published Azure CLI 2.91.0 ARM64 macOS artifact independently.

    We downloaded the release archive directly with curl:

    curl -fL \
  https://github.com/Azure/azure-cli/releases/download/azure-cli-2.91.0/azure-cli-2.91.0-macos-arm64.tar.gz \
  -o /tmp/azure-cli-2.91.0-macos-arm64.tar.gz

EXTRACT_DIR="$(mktemp -d /tmp/azure-cli-2.91.0.XXXXXX)"
tar -xzf /tmp/azure-cli-2.91.0-macos-arm64.tar.gz -C "$EXTRACT_DIR"

    We then extracted that archive, inventoried every Mach-O object, and verified each object with Apple's codesign tooling. All 12 native .so/.dylib objects passed strict signature verification. Each object was valid on disk, satisfied its designated requirement, included hardened runtime and a secure timestamp, and reported the Microsoft Developer ID certificate chain. Representative details were:

    find "$EXTRACT_DIR" -type f \( -name '*.so' -o -name '*.dylib' \) -print0 \
  | while IFS= read -r -d '' FILE; do
      printf '\n=== %s ===\n' "$FILE"
      codesign --verify --strict --verbose=4 "$FILE" || exit 1
      codesign -dvvv "$FILE" 2>&1 \
        | grep -E '^(CodeDirectory|Authority|Timestamp|TeamIdentifier)'
    done
    CodeDirectory v=20500 flags=0x10000(runtime)
Authority=Developer ID Application: Microsoft Corporation (UBF8T346G9)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=29 Sep 2026
TeamIdentifier=UBF8T346G9

    We also checked the final extracted objects against Apple's online notarization requirement:

    NOTARIZATION_FAILURES=0
while IFS= read -r -d '' FILE; do
  printf '\n=== %s ===\n' "$FILE"
  codesign --verify --strict --check-notarization \
    --test-requirement '=notarized' --verbose=4 "$FILE" \
    || (( NOTARIZATION_FAILURES += 1 ))
done < <(find "$EXTRACT_DIR" -type f \
  \( -name '*.so' -o -name '*.dylib' \) -print0)
printf '\nNotarization failures: %d\n' "$NOTARIZATION_FAILURES"

    Every object returned the following successful result:

    valid on disk
satisfies its Designated Requirement
explicit requirement satisfied

    The aggregate result across all 12 objects was:

    Notarization failures: 0

    The Apple Root CA entry above demonstrates the signing certificate chain. The separate =notarized requirement check and explicit requirement satisfied result demonstrate that Apple's notarization service recognizes the final code object. Together, these establish that the release archive contains valid Microsoft-signed and Apple-notarized native code.

    One important distinction is that Homebrew Cask intentionally applies com.apple.quarantine to downloaded and installed files. A signed and notarized file can therefore still carry the quarantine attribute. The expected behavior is that Gatekeeper assesses and permits the signed/notarized code; the expected behavior is not that the quarantine attribute is absent.

    We also tested a clean Homebrew installation after removing the cached 2.91.0 cask archive and forcing a fresh download. All 12 installed native objects retained com.apple.quarantine. With quarantine still present, az version succeeded and all representative native modules loaded without a Gatekeeper dialog. The macOS policy log recorded GK evaluateScanResult: 1 for all 12 Azure CLI native objects, identified them with Microsoft team ID UBF8T346G9, and cleared their Gatekeeper denial breadcrumbs.

    Because quarantine was manually removed from files in the current installation, could you please perform one clean reinstall so we can test the original state? The following does not use --zap, so it should preserve ~/.azure and installed Azure CLI extensions.

    First, please capture the exact environment:

    sw_vers
uname -m
brew config

    Please run these commands in order:

    brew uninstall --cask azure-cli
brew cleanup --scrub --prune=all azure-cli
brew fetch --cask --force azure-cli
brew install --cask azure-cli
brew list --cask --versions azure-cli

    Please do not run az yet. First capture the installation and quarantine state:

    INSTALL_DIR="$(brew --prefix)/Caskroom/azure-cli/2.91.0"

find "$INSTALL_DIR" -type f \( -name '*.so' -o -name '*.dylib' \) -print0 \
  | while IFS= read -r -d '' FILE; do
      printf '\n=== %s ===\n' "$FILE"
      xattr -l "$FILE"
    done > /tmp/azure-cli-xattrs-before-first-run.txt

LOG_START="$(date -u '+%Y-%m-%d %H:%M:%S%z')"
printf 'Gatekeeper test start: %s\n' "$LOG_START"

    Then run the first launch test:

    az version

    Next, force the representative native modules to load:

    PYTHONPATH="$INSTALL_DIR/libexec/lib/python3.14/site-packages" \
  /opt/homebrew/opt/python@3.14/bin/python3.14 -c '
import _cffi_backend
import bcrypt._bcrypt
import charset_normalizer.cd, charset_normalizer.md
import cryptography.hazmat.bindings._rust
import nacl._sodium
import psutil._psutil_osx, psutil._psutil_posix
import pymsalruntime
import wrapt._wrappers
import yaml._yaml
print("Native module imports: PASS")
'

    Finally, retry the original k9s/AKS operation that produced the dialogs.

    For each of these tests, please let us know whether a Gatekeeper dialog appears. If it does, please record which command triggered it and the exact file path shown in the dialog, then run the following with that path:

    REJECTED_FILE='/exact/path/from/the/dialog.so'

xattr -l "$REJECTED_FILE"
codesign --verify --strict --verbose=4 "$REJECTED_FILE"
codesign -dvvv "$REJECTED_FILE"
codesign --verify --strict --check-notarization \
  --test-requirement '=notarized' --verbose=4 "$REJECTED_FILE"

/usr/bin/log show --start "$LOG_START" --style compact \
  --predicate '(process == "syspolicyd") OR (process == "trustd") OR (subsystem == "com.apple.security.syspolicy")' \
  > /tmp/azure-cli-gatekeeper.log

    Please attach these two files:

    /tmp/azure-cli-xattrs-before-first-run.txt
/tmp/azure-cli-gatekeeper.log

    It would also help to know whether the Mac is MDM-managed and whether the test was performed behind a VPN, proxy, TLS-inspection service, DNS/security filter, or endpoint-security product. Standalone .so files rely on Apple's online notarization-ticket lookup during assessment, so blocked or intercepted access to Apple's trust services can produce a machine- or network-specific failure even when the artifact bytes and signatures are valid.

    Please do not remove com.apple.quarantine, use brew install --no-quarantine, disable Gatekeeper, or use brew uninstall --zap during this test, because those actions would remove the state needed to diagnose the failure.

  11. squerble commented on Oct 8, 2026

    @squerble
    squerble
    on Oct 8, 2026
    Author

    Thank you Naga Nandyala (@naga-nandyala) .

    First three environment capture commands:

    sw_vers
ProductName:            macOS
ProductVersion:         26.7.1
BuildVersion:           25G241

uname -m
arm64

brew config
HOMEBREW_VERSION: 7.0.8
ORIGIN: https://github.com/Homebrew/brew
HEAD: a57af195cf9d7addb48bdb1204c9151313cd0057
Last commit: 4 days ago
Branch: stable
Core tap: N/A
Core cask tap: N/A
HOMEBREW_PREFIX: /opt/homebrew
Homebrew Ruby: 4.0.7 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/4.0.7/bin/ruby
CPU: octa-core 64-bit arm_ibiza
Clang: 21.0.0 build 2100
Git: 2.56.0 => /opt/homebrew/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 26.7.1-arm64
CLT: 27.0.0.0.1788430756
Xcode: 26.5
Metal Toolchain: 17.0 (17F42)
Rosetta 2: false

    Clean install instructions followed and first temp file generated.

    azure-cli-xattrs-before-first-run.txt

    Results

    Running az version

    Gatekeeper immediately popped up:

    "_psutil_osx.abi3.so" Not Opened
Apple could not verify "\_psutil\_osx.abi3.so" is free of malware that may harm your Mac or compromise your privacy.

    Not specfic path given but:

    find /opt/homebrew/ -name "_psutil*.so"
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_posix.abi3.so
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so

    Ran your script against the matching filename (I did attach file but looks to have corrupted. Output below).

    com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so: valid on disk
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so: satisfies its Designated Requirement
Executable=/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so
Identifier=_psutil_osx.abi3
Format=Mach-O thin (arm64)
CodeDirectory v=20500 size=860 flags=0x10000(runtime) hashes=21+2 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=f489189d8dae555a6a87cbe947e421456b394887
CandidateCDHashFull sha256=f489189d8dae555a6a87cbe947e421456b3948877ae70d4c9f318ff4cdb9826f
Hash choices=sha256
CMSDigest=f489189d8dae555a6a87cbe947e421456b3948877ae70d4c9f318ff4cdb9826f
CMSDigestType=2
CDHash=f489189d8dae555a6a87cbe947e421456b394887
Signature size=9013
Authority=Developer ID Application: Microsoft Corporation (UBF8T346G9)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=29 Sep 2026 at 08:09:37
Info.plist=not bound
TeamIdentifier=UBF8T346G9
Runtime Version=14.5.0
Sealed Resources=none
Internal requirements count=1 size=176
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so: valid on disk
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so: satisfies its Designated Requirement
test-requirement: code failed to satisfy specified code requirement(s)
log: Failed conversion of '' using format '%Y-%m-%d'

    The same Gatekeeper dialog popped up again for the same file, but then az version was able to complete:

    az version
{
  "azure-cli": "2.91.0",
  "azure-cli-core": "2.91.0",
  "azure-cli-telemetry": "1.1.0",
  "extensions": {
    "alb": "2.0.1"
  }
}

    This particular Mac is indeed MDM-managed via JAMF, is currently connected to the corporate VPN (Cisco GlobalProtect) including TLS inspection. No DNS filter but runs Sophos Endpoint Protection.

    Would it be worth me having a temporary VPN exception granted and running the same steps above with the VPN fully disconnected and running only on my home's ISP connection?

  12. squerble commented on Oct 8, 2026

    @squerble
    squerble
    on Oct 8, 2026
    Author

    I went ahead and tried it with VPN disabled. No issues at all, all commands working without triggering any Gatekeeper warnings.

    Outputs of the two log files from the scripts:

    === /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/cryptography/hazmat/bindings/_rust.abi3.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/bcrypt/_bcrypt.abi3.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/wrapt/_wrappers.cpython-314-darwin.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/charset_normalizer/md.cpython-314-darwin.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/charset_normalizer/cd.cpython-314-darwin.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/pymsalruntime/libmsalruntime_arm64.dylib ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/pymsalruntime/pymsalruntime.cpython-314-darwin.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/nacl/_sodium.abi3.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/yaml/_yaml.cpython-314-darwin.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_posix.abi3.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

=== /opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/_cffi_backend.cpython-314-darwin.so ===
com.apple.provenance:
com.apple.quarantine: 0381;6ac783fc;;355777BC-CCF5-48E6-B495-23D302406961

    and

    com.apple.provenance:
com.apple.quarantine: 0381;6ac78ab5;;E40E9FD4-4E83-4D3B-9A10-2E289E97EACE
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so: valid on disk
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so: satisfies its Designated Requirement
Executable=/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so
Identifier=_psutil_osx.abi3
Format=Mach-O thin (arm64)
CodeDirectory v=20500 size=860 flags=0x10000(runtime) hashes=21+2 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=f489189d8dae555a6a87cbe947e421456b394887
CandidateCDHashFull sha256=f489189d8dae555a6a87cbe947e421456b3948877ae70d4c9f318ff4cdb9826f
Hash choices=sha256
CMSDigest=f489189d8dae555a6a87cbe947e421456b3948877ae70d4c9f318ff4cdb9826f
CMSDigestType=2
CDHash=f489189d8dae555a6a87cbe947e421456b394887
Signature size=9013
Authority=Developer ID Application: Microsoft Corporation (UBF8T346G9)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=29 Sep 2026 at 08:09:37
Info.plist=not bound
TeamIdentifier=UBF8T346G9
Runtime Version=14.5.0
Sealed Resources=none
Internal requirements count=1 size=176
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so: valid on disk
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so: satisfies its Designated Requirement
/opt/homebrew/Caskroom/azure-cli/2.91.0/libexec/lib/python3.14/site-packages/psutil/_psutil_osx.abi3.so: explicit requirement satisfied
log: Could not open local log store: Operation not permitted

    EDIT: At this point, I assume it would be worth closing this ticket as this is clearly an issue caused by my job's VPN and so this will have to be looked at on their side. I apologise for taking up time.

  13. naga-nandyala commented on Oct 8, 2026

    @naga-nandyala
    Naga Nandyala (naga-nandyala)
    on Oct 8, 2026
    Contributor

    Thanks for confirmation

  14. Naga Nandyala (naga-nandyala)
    closed this as completedon Oct 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Azure CLI TeamThe command of the issue is owned by Azure CLI teambugThis issue requires a change to an existing behavior in the product in order to be resolved.customer-reportedIssues that are reported by GitHub users external to the Azure organization.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions