Kubelogin Path Resolution Failure

“az aks get-credentials fails with Error running kubelogin: [Errno 2] No such file or directory: '' despite kubelogin correctly installed and on PATH ### 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 "<cluster-name>" as current context in <config-file> 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 ”