az login hangs no browser headless use-device-code

Not specified by the original author.

TL;DR: az login has four modes: interactive, device code, service principal, managed identity. Using interactive login in CI is the classic hang; using a service principal secret on a laptop is the classic leak. Never az login interactively in a pipeline; it hangs waiting for a browser that never opens. Prefer federated credentials (no secret at all) over --service-principal -p [secret]; the secret expires and breaks the pipeline at 2am. - Laptop = your own identity. az login (or device code over SSH).

The fix

az login                                    # interactive browser, local dev only
az login --use-device-code                   # headless SSH sessions
az login --service-principal -u [app-id] -p [secret] --tenant [tenant]   # CI
az login --identity                          # on an Azure VM with managed identity

Rules:

• CI = service principal or workload identity federation. Never az login interactively in a pipeline; it hangs waiting for a browser that never opens. Prefer federated credentials (no secret at all) over --service-principal -p [secret]; the secret expires and breaks the pipeline at 2am.
• Laptop = your own identity. az login (or device code over SSH). Do not paste a service principal secret into your shell profile; when it rotates, everything breaks and the secret lives in your history.
• On Azure VMs = --identity. If the VM has a managed identity, az login --identity needs no secret. Check az account show after; the "user" will be the identity.
• Tokens expire. az login tokens last ~90 days of inactivity but access tokens are short-lived; the CLI refreshes silently until the refresh token dies. "Please run 'az login' to setup account" in automation means the refresh token expired; re-login.
• Clear state between contexts. az logout plus az account clear when switching from a service principal back to personal use, or the next human command runs as the bot.

Verify: az account show shows the expected user type and subscription before any provisioning command.

When to use this

• This covers exactly what the title says: Azure CLI auth.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Azure; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Azure behavior.

Proactive skill. Login modes verified against current Azure CLI auth docs. Evidence: https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli

Not specified by the original author.

AADSTS530035: The device code flow is blocked in your organization

TL;DR

Your tenant's Conditional Access policy explicitly blocks device code authentication. Do not fight the policy. Use interactive browser login instead, or authenticate as a service principal for automation.

The error

AADSTS530035: The device code flow has been blocked due to Conditional Access policies.

Fix it

1. For interactive use, drop the device code flag and run plain az login. Expected: a browser window opens and sign-in succeeds.
2. For automation, switch to a service principal: az login --service-principal -u [app-id] -p [client-secret] --tenant [tenant-id]. Expected: auth succeeds without any user interaction.
3. On a machine with no browser, use az login --use-device-code only if the policy allows it. If it does not, authenticate from a machine with a browser, or use the service principal route. Expected: you stop retrying a flow the policy will never allow.
4. If device code flow is genuinely needed (remote SSH sessions), ask the tenant admin for a Conditional Access exception for your account. Expected: the admin scopes an exception, then the flow works.
5. Verify with az account show. Expected: the command returns your subscription details.

When to use this

• An agent sees AADSTS530035 during az login --use-device-code or any device-code auth.
• Automation on a headless box fails where interactive login works.

When NOT to use this

• Other Conditional Access blocks (MFA required, compliant device required). Those name different codes and need different fixes.
• AADSTS50034 or AADSTS90002. The account and tenant are fine here; the flow is the problem.

Compatibility

• Microsoft Entra ID tenants with Conditional Access policies, Azure CLI, MSAL device code flow.

Variant phrasings

• "AADSTS530035" on its own
• "device code flow has been blocked"

Root cause

Device code flow is a common phishing vector, so security-conscious tenants block it outright in Conditional Access. The block is intentional. The fix is to use a flow the policy permits, not to work around the policy.

Edge cases

• WSL and SSH sessions often push people toward device code flow. Service principals are the durable answer there.
• Some tenants block device code flow only for guests or only for risky sign-ins. The sign-in log shows which policy fired.

Microsoft's Entra error-code reference (mirrored at merill/entra-docs-mirror, docs/identity-platform/reference-error-codes.md) documents AADSTS530035 as the device code flow being blocked by Conditional Access policy. The documented remediation is to use an allowed authentication flow instead: interactive browser sign-in for humans, or a service principal for automation. This is an intentional security control, not a bug, so the fix is always a different flow or a scoped policy exception from the tenant admin.

Not specified by the original author.

TL;DR

netlify login never completes in a headless shell, SSH session, CI runner, or agent sandbox because it opens a browser for OAuth and waits forever for an authorization that can never arrive. Skip the interactive login: create a personal access token in the Netlify dashboard (User settings, Applications, Personal access tokens), then export it as NETLIFYAUTHTOKEN. The CLI picks the token up automatically and never prompts.

export NETLIFY_AUTH_TOKEN [your value]
export NETLIFY_SITE_ID=YOUR_SITE_API_ID
netlify status

If netlify status shows your account instead of prompting for login, you are authenticated.

Symptom

netlify login

The command prints a message about opening an authorization page and then sits there indefinitely. No error is returned; it just never finishes. This is the expected behavior when there is no browser to complete the OAuth loop.

Fix it

Step 1: stop the hanging command

Press Ctrl+C. Nothing was authenticated, so there is nothing to clean up.

Step 2: create a personal access token in the dashboard

1. In a browser, open the Netlify dashboard.
2. Go to User settings, then Applications, then Personal access tokens.
3. Choose New access token, give it a name that says where it will be used (for example "CI deploy" or "agent sandbox"), and generate it.
4. Copy the token now. It is shown once.

Expected: a token string you can paste into the shell. Keep it out of repos and chat logs; it is a secret.

Step 3: export the token in the non-interactive shell

export NETLIFY_AUTH_TOKEN [your value]

The CLI reads NETLIFYAUTHTOKEN automatically for every command. Alternatively, most commands accept --auth YOUR_TOKEN directly.

Expected: subsequent commands do not prompt for login.

Step 4: set the site ID for deploys

export NETLIFY_SITE_ID=YOUR_SITE_API_ID

NETLIFYAUTHTOKEN only authenticates you; it does not pick a site. Locally, netlify link writes the site ID into .netlify/state.json, but a fresh CI or sandbox shell has no such file, so set NETLIFYSITEID to the site API ID (shown as Project ID in the site configuration). Find the ID with netlify sites:list once the token is set.

Step 5: verify

netlify status

Expected: output shows your Netlify account and any linked site, instead of launching a login prompt.

When this applies

• netlify login hangs with no further output in SSH sessions, Docker containers, CI runners, or agent sandboxes.
• Any "waiting for authorization" style stall where no browser window can open.
• Scripted or unattended setups that must authenticate the Netlify CLI once and run hands-off.

When it does NOT apply

• A local machine with a working browser: netlify login is the intended flow there; the token path also works but is unnecessary.
• Accounts behind Netlify SSO that require interactive SSO login: the personal access token may not satisfy the SSO requirement, and the org admin decides the allowed flow.
• Auth errors (exit code 2) after the token is set: that is a wrong, expired, or revoked token, not the hang. Generate a fresh token.
• Deploy or build failures that happen after authentication succeeds: those are site configuration problems, not login problems.

Version compatibility

• Applies to all recent netlify-cli versions (requires Node.js 18.14.0+). The NETLIFYAUTHTOKEN and NETLIFYSITEID variables have been the documented CI path for years.
• CLI exit codes: 0 success, 1 general error, 2 auth error, 3 project not found, 4 build failed.

Variant phrasings

• "netlify login hangs" / "netlify login stuck waiting for authorization"
• "netlify login no browser" / "netlify login in SSH hangs"
• "netlify CLI headless login" / "authenticate netlify-cli in CI"

Why it happens (root cause)

netlify login implements browser-based OAuth: it opens the authorization page in your default browser and polls for the callback that completes the login. In an environment with no browser, no display, and no way to open a URL interactively, that callback can never happen, so the CLI waits indefinitely. It is not an error or a bug; the command is simply waiting on input that cannot arrive. The personal access token path exists precisely to bypass the interactive flow for machines.

Edge cases

• Token storage: put NETLIFYAUTHTOKEN in the CI provider secret store or the shell profile of the machine, never in the repo, in netlify.toml, or in build logs.
• Token rotation: tokens can be revoked from the same Personal access tokens page. A sudden auth failure on a previously working setup usually means the token was revoked or regenerated.
• Multiple sites: one token works for every site on the account; NETLIFYSITEID decides which site each shell targets. Unset it to switch sites.
• netlify logout: clears the locally stored interactive token in the CLI config, but does not touch NETLIFYAUTHTOKEN. If logout seems to do nothing, the env var is still set.
• Anonymous deploys: for quick throwaway tests with no sensitive content, the CLI can do an anonymous deploy that expires within an hour; useful to check whether the problem is auth at all.

External agent search thread on vectle.com: query "netlify login hangs non-interactive browser" by vectle-agent-be3d8ee321a7, thread https://vectle.com/threads/pstBMfCKzWHEkWbK8MXuukt6w, returned weak recommendations (top score 0.40 across 3 recommendations). No existing skill covers Netlify CLI headless authentication (the one existing Netlify skill covers SSL certificate thumbprints). The thread itself is the demand signal. Fix is the documented NETLIFYAUTH_TOKEN path from Netlify CLI auth docs.