az not recognized after visual studio code restart error terminal path

Not specified by the original author.

TL;DR

az is not recognized as an internal or external command means Windows cannot find the Azure CLI executable: the CLI installed but its folder is not on PATH, or the install did not finish. Reinstall from the official MSI with the add to PATH option checked, or add the install folder to PATH manually, then open a fresh terminal and verify with az version. A terminal opened before the fix will never see the new PATH.

'az' is not recognized as an internal or external command,
operable program or batch file.

Use this when

• cmd prints az is not recognized as an internal or external command, operable program or batch file
• PowerShell prints the term az is not recognized as the name of a cmdlet
• This happens right after installing the Azure CLI on Windows, or in a terminal that was open during the install

Not for this skill when

• az runs but az login fails. The CLI is found there; authentication is the problem, see the related application id skill below
• You are inside Azure Cloud Shell. Cloud Shell always has the CLI; a not recognized message there is a different issue

Steps

1. Check whether the CLI is actually installed. Look for Azure CLI in Add or remove programs, and for its folder under Program Files.

Expected: you know whether this is a missing install (go to step 3) or a PATH problem (go to step 2).

2. If it is installed, add its folder to PATH. Add the Azure CLI bin folder to the system PATH in Environment Variables, then close the terminal completely and open a new one.

Expected: az version prints version info in the fresh terminal.

3. If it is not installed, or the folder is missing, reinstall from the official MSI and keep the add to PATH option checked.

Expected: the installer completes, and a fresh terminal finds az.

4. In PowerShell, confirm the shell resolves it: Get-Command az.

Expected: it resolves to the CLI executable path instead of an error.

5. Verify the install end to end: az version.

Expected: JSON output with the Azure CLI version. Only now try az login or your original command.

Variant phrasings

az not recognized windows

The short version of the same report. It is the PATH problem in step 2 nine times out of ten; do the fresh-terminal check before reinstalling.

the term az is not recognized as the name of a cmdlet

The PowerShell wording of the identical failure. PowerShell and cmd read the same PATH, so the fix is the same: folder on PATH, fresh terminal, Get-Command az to confirm.

az login not recognized

az login never gets to run because the shell cannot find az at all. Fix PATH first (steps 1 to 5); login errors only become visible after az version works.

Root cause

The MSI installer optionally adds the CLI folder to PATH. Unchecking that option, an install that did not finish, or a terminal opened before the install leaves az unresolvable. The step everyone skips is opening a fresh terminal: already-open shells keep the old PATH forever.

Edge cases

• 32-bit and 64-bit installs land in different Program Files folders. Point PATH at the one that actually exists on disk.
• Corporate images sometimes block the MSI PATH change. Set PATH manually in System environment variables instead.
• Multiple Python-based CLI installs can shadow each other. Get-Command az shows which executable the shell actually resolved.

Tool compatibility

Azure CLI on Windows (MSI install), in cmd and PowerShell. The PATH principle is the same for winget installs; the folder location differs.

Related skills

• Please run az login to setup account - the next failure after az is found but not signed in: https://vectle.com/skills/skl_7aKi9fDg6cP5dqjxQPgTHA
• application id not found (AADSTS700016), which az login can hit once the CLI runs: https://vectle.com/skills/skl_A8TLFys-hrvLfD1hrxFnDg
• azure identity not found: https://vectle.com/skills/skl_O0wm7fdvw17HY02tjklDMw

Provenance

Built from the hatchjs.com Q and A on this exact error, linked in the evidence.

The hatchjs.com Q&A ("az is not recognized as an internal or external command") and the kthw-powershell execution troubleshooting notes document this exact failure: after installing the Azure CLI on Windows, the shell cannot find az because the install folder is not on PATH. The confirmed fix is reinstalling with PATH registration or adding the install folder to PATH manually, then opening a fresh terminal session so the new PATH takes effect.

Not specified by the original author.

Please run 'az login' to setup account.

TL;DR: your CLI session died. Cached tokens expire after about 90 days, and az wont tell you gracefully — it just says to set up your account. Run az account clear to drop the stale cache, then az login to sign in fresh. Verify with az account show.

Please run 'az login' to setup account.

Steps

1. Confirm the session is dead:

az account show

Expected: the same error instead of account JSON.

2. Clear the stale cache:

az account clear

Expected: no output.

3. Log in fresh:

az login

Expected: browser opens; after sign-in the CLI lists your subscriptions. Headless box: az login --use-device-code. Multiple tenants: add --tenant [tenant id].

4. Verify:

az account show

Expected: JSON with your subscription, tenant ID, and user name.

5. If you have several subscriptions, pick the right one:

az account list --output table
az account set --subscription [name or id]

When this applies

• the exact Please run 'az login' to setup account. error
• commands that worked months ago and now fail everywhere
• after a password change, or after the ~/.azure cache was deleted or moved

When it doesnt

• AADSTS53003 from Conditional Access — that is policy blocking the login, re-running az login wont help until the policy allows it
• AADSTS50020 (account does not exist in tenant) — you are in the wrong tenant; use az login --tenant [tenant id]
• az login itself hanging with no browser — that is the headless case, use az login --use-device-code

Compatibility

Azure CLI 2.x, all platforms.

Why it happens

The CLI caches tokens under ~/.azure and silently refreshes them until the refresh token itself dies (about 90 days, sooner after a password change). Once it is dead every command fails with the setup-account message, which reads like you never logged in.

Edge cases

• az account get-access-token forces a refresh check and shows the real error when the cache is half-dead
• AZURECONFIGDIR isolates caches per terminal: logging in in one terminal doesnt log in the other
• service principal logins expire too — re-run az login --service-principal with fresh credentials, not plain az login

Find this skill again

curl -s 'https://vectle.com/api/v1/search?q=az+please+run+az+login+to+setup+account'

Azure CLI users hit Please run 'az login' to setup account when the cached session expired — sessions go stale after about 90 days — even though they had logged in before. The verified fix: az account clear to drop the dead cache, then az login to sign in fresh (az login --use-device-code on headless boxes, --tenant for multi-tenant setups), confirmed with az account show. Source: https://github.com/codetocloudorg/azure_essentials/blob/HEAD/wiki/Troubleshooting.md

Not specified by the original author.

The term 'Get-AzVM' is not recognized as the name of a cmdlet

TL;DR

The Az PowerShell module is not installed (or not loaded) in your session. Install it from the PowerShell Gallery, import it, and the cmdlets appear. Do not confuse this with the az CLI; they are different tools.

The error

The term 'Get-AzVM' is not recognized as the name of a cmdlet, function, script file, or operable program.

Fix it

1. Install the module: Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force. Expected: the install completes without errors.
2. Import it: Import-Module Az. Expected: no output, meaning success.
3. Verify: Get-Command Get-AzVM. Expected: it resolves to the Az.Compute cmdlet.
4. Connect: Connect-AzAccount. Expected: interactive login succeeds.
5. Retry your command. Expected: Get-AzVM returns your VMs.

When to use this

• An agent sees "not recognized as the name of a cmdlet" for any Get-Az, New-Az, or Set-Az* command.
• Fresh machines or CI agents running Azure PowerShell for the first time.

When NOT to use this

• "'az' is not recognized". That is the Azure CLI, a separate install.
• AzureRM cmdlets (Get-AzureRmVM). Those are the retired module; migrate to Az.

Compatibility

• PowerShell 5.1 and 7+, Az module (current). AzureRM is retired and should not be installed.

Variant phrasings

• "The term 'Connect-AzAccount' is not recognized"
• Any "not recognized as the name of a cmdlet" for Az.* commands

Root cause

Windows ships no Azure modules. The Az module comes from the PowerShell Gallery, and without it PowerShell has no idea what Get-AzVM is. CI agents and fresh VMs hit this on every first run until the module install becomes part of setup.

Edge cases

• Both AzureRM and Az installed side by side cause conflicts. Uninstall AzureRM.
• Execution policy can block the install. Set-ExecutionPolicy RemoteSigned -Scope CurrentUser first if needed.

The troubleshooting guide at syncluv/azure-mastery-labs (troubleshooting.md) documents the "AzPowerShell module not found" pattern: Azure PowerShell cmdlets like Get-AzVM fail with "not recognized as the name of a cmdlet" when the Az module is missing, with the fix being Install-Module Az followed by Connect-AzAccount. The same guide notes the parallel Azure CLI symptom ("az is not recognized") as a separate PATH problem, confirming these are two distinct tools with distinct fixes.