az aks get-credentials fails with Error running kubelogin: [Errno 2] No such file or directory: '' despite kubelogin correctly installed and on PATH

[awangptc]

Describe the bug

Running az aks get-credentials against an AAD-enabled AKS cluster successfully writes the kubeconfig, but immediately after merging the context, the command prints:

Merged "" as current context in
Error running kubelogin: [Errno 2] No such file or directory: ''

This appears to come from the new automatic kubelogin-conversion behavior added in #32167 (auto-running kubelogin convert-kubeconfig -l azurecli when the kubeconfig requires device-code auth). The empty string ('') passed as the executable path suggests the internal lookup used by this feature is not resolving kubelogin's path correctly, even though kubelogin is verifiably installed and on PATH.

As a result, the automatic conversion to azurecli login mode never happens, and the generated kubeconfig is left in devicecode login mode:

users:
- name: clusterUser_<resource-group>_<cluster-name>
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - get-token
      - --environment
      - AzurePublicCloud
      - --server-id
      - <aad-server-id>
      - --client-id
      - <aad-client-id>
      - --tenant-id
      - <aad-tenant-id>
      - --login
      - devicecode
      command: kubelogin
      env: null
      installHint: |

        kubelogin is not installed which is required to connect to AAD enabled cluster.

        To learn more, please go to https://aka.ms/aks/kubelogin

This defeats the purpose of #32167, since the first kubectl command against the cluster then triggers an interactive device-code login prompt rather than transparently using the Azure CLI token as intended.

Related command

az aks get-credentials --name <cluster-name> --resource-group <resource-group> -f <config-file> --subscription <subscription> --overwrite-existing

Errors

Merged "<cluster-name>" as current context in <config-file>
Error running kubelogin: [Errno 2] No such file or directory: ''

Issue script & Debug output

I've confirmed kubelogin itself is not the problem:

$ which kubelogin
/opt/homebrew/bin/kubelogin

$ /opt/homebrew/bin/kubelogin --version
kubelogin version
git hash: v0.2.19/a9b10fbf8422f0c5b687eb58f26d7995f2fe206d
Go version: go1.26.4
Build time: 2026-06-23T17:26:47Z
Platform: darwin/arm64

$ ls -l /usr/local/bin/kubelogin
-rwxr-xr-x  1 root  wheel  59970930 Sep 16 12:33 /usr/local/bin/kubelogin

$ /usr/local/bin/kubelogin --version
kubelogin version
git hash: v0.2.19/a9b10fbf8422f0c5b687eb58f26d7995f2fe206d
Go version: go1.26.4
Build time: 2026-06-23T17:26:47Z
Platform: darwin/arm64

Both installs (Homebrew at /opt/homebrew/bin, and the one from az aks install-cli at /usr/local/bin) are the same version, both executable, and the Homebrew one correctly resolves first on PATH.

Manually running kubelogin convert-kubeconfig -l azurecli after get-credentials works around the issue completely (converting the kubeconfig from devicecode to azurecli login mode as expected), which points at the bug being in az CLI's internal invocation of kubelogin during get-credentials, not in kubelogin itself or PATH resolution in my shell.

Expected behavior

az aks get-credentials should successfully run the automatic kubelogin conversion as intended by #32167 (leaving the kubeconfig in azurecli login mode), or fail gracefully with a clear message if it genuinely can't find kubelogin — not emit an empty-path Errno 2 while silently leaving the kubeconfig in devicecode mode.

Environment Summary

$ az --version
azure-cli                         2.90.0
core                              2.90.0
telemetry                          1.1.0

Extensions:
bastion                            1.4.3
ssh                                2.0.6

Dependencies:
msal                              1.36.0
azure-mgmt-resource               24.0.0

OS: macOS (Apple Silicon, darwin/arm64)
kubelogin: v0.2.19 (installed via both Homebrew and az aks install-cli)
Related: #32167 (introduced the auto-conversion behavior), possibly related to #32313 (sporadic "kubelogin: command not found" on the same feature in CI agents)

Additional context

No response

[yonzhan]

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