🚨 Pulumi Error: 'PULUMI_ACCESS_TOKEN must be set for login during non-interactive CLI sessions' — Cause, Fix, and Troubleshooting Guide

Overview

error: PULUMI_ACCESS_TOKEN must be set for login during non-interactive CLI sessions means Pulumi tried to log in to the Pulumi Cloud backend but has no credentials and cannot open an interactive browser login. In a terminal, pulumi login would prompt you to paste a token or open a browser; in CI, scripts, or containers there is no interactive session, so Pulumi requires the token via the PULUMI_ACCESS_TOKEN environment variable.

This surfaces the first time a non-interactive run needs the backend — typically pulumi login, pulumi stack select, pulumi up, or pulumi preview in a pipeline that has never been authenticated.

error: PULUMI_ACCESS_TOKEN must be set for login during non-interactive CLI sessions

Symptoms

• A CI/CD job fails at the first Pulumi command with the PULUMI_ACCESS_TOKEN must be set line.
• The same commands work on your laptop (where ~/.pulumi/credentials.json already holds a token).
• pulumi whoami fails or reports you are not logged in.
• A fresh container or runner has no cached Pulumi credentials.

Common Root Causes

1. No token exported in CI

The runner has never run an interactive pulumi login, and PULUMI_ACCESS_TOKEN is not set, so there is nothing to authenticate with.

env var PULUMI_ACCESS_TOKEN is empty

2. Targeting Pulumi Cloud when you meant a self-managed backend

If you intended to use a local or object-storage backend, Pulumi defaulting to app.pulumi.com will demand a token you do not need.

3. Token set in the wrong scope

The variable is exported in one step or shell but the pulumi command runs in a different step, sub-shell, or container image.

4. Expired, revoked, or wrong token

A token that was deleted in the Pulumi Cloud console, or a personal token used where an organization token is required, still leads to a failed login.

5. Ephemeral home directory

Containers that reset $HOME lose ~/.pulumi/credentials.json between runs, so each job starts unauthenticated.

How to Diagnose

Check whether you are logged in and to which backend:

pulumi whoami --verbose

Confirm the token variable is present in the job’s environment:

printenv PULUMI_ACCESS_TOKEN | wc -c

See which backend URL Pulumi will use:

pulumi login --help
cat ~/.pulumi/credentials.json 2>/dev/null || echo "no cached credentials"

Fixes

Export a Pulumi Cloud access token: Create a token in the Pulumi Cloud console (Settings → Access Tokens) and export it before any Pulumi command.

export PULUMI_ACCESS_TOKEN='pul-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
pulumi login
pulumi up --stack myorg/myproject/prod

Wire it into CI as a masked secret: Add the token as a protected/secret variable and reference it in the job environment.

# GitHub Actions:
#   env:
#     PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
pulumi preview

Log in with the token non-interactively: You can pipe the token into pulumi login if you prefer explicit login.

echo "$PULUMI_ACCESS_TOKEN" | pulumi login

Use a self-managed backend instead (no token needed): If you did not intend to use Pulumi Cloud, log in to a local or object-storage backend.

pulumi login --local
# or
pulumi login s3://my-pulumi-state-bucket

Persist credentials in the container: Cache ~/.pulumi/credentials.json or set PULUMI_HOME to a persistent path so repeated jobs stay authenticated. Setting the env var is still the most reliable approach for CI.

export PULUMI_HOME=/cache/pulumi

Rotate a bad token: If the token was revoked or expired, generate a new one in the console and update the CI secret.

What to Watch Out For

• PULUMI_ACCESS_TOKEN must be set in the same environment/step that runs pulumi; exporting it earlier in a different shell usually does not carry over.
• The error specifically means Pulumi Cloud login — if you use S3/Azure/GCS/local state, switch backends with pulumi login <url> rather than supplying a token.
• Tokens are secrets; store them in the CI secret store and never print them to logs.
• Organization stacks (myorg/project/stack) may require an organization-scoped token, not a personal one.
• A cached login on your laptop hides the problem — always test pipelines in a clean environment.
• Use short-lived or scoped tokens where possible and rotate them regularly.

Related Guides

• Pulumi Error: ‘no stack named dev found’ — Troubleshooting Guide
• Pulumi Error: ‘passphrase must be set’ — Troubleshooting Guide
• Pulumi Error: ‘another update is currently in progress’ — Troubleshooting Guide