flyctl wrong account FLY_API_TOKEN overrides auth login

Not specified by the original author.

FLY_API_TOKEN overrides your interactive login silently. If fly auth whoami shows the wrong user, check env | grep FLY_ for a stale export, then unset FLY_API_TOKEN (or update it to the right token). The env var always wins over flyctl auth login.

$ fly auth whoami
wrong-user   # expected: your-user, right after a fresh flyctl auth login

Fix

1. Check for the override:

   env | grep FLY_

   Expected culprit: FLY_API_TOKEN set to an old or different account's token.

2. See which credential is actually active:

   fly auth token

   Compare it against the token in ~/.fly/config.yml. If they differ, the env var is winning.

3. Remove or correct it:

   unset FLY_API_TOKEN

   Expected: fly auth whoami now shows the logged-in user.

4. Make it permanent: delete the export from ~/.bashrc, ~/.zshrc, direnv files, or IDE run configs.

When this applies

• fly auth whoami disagrees with your last flyctl auth login.
• Deploys land in the wrong account or org right after switching users.

When it does NOT apply

• 401 errors: the token (whichever one is active) is dead; refresh it.
• No token anywhere: No access token available; just log in.

Compatibility

• flyctl (all recent versions).

Why it happens

Precedence is env var first, stored login second. The env var exists for CI, where there is no login, but it lingers in interactive shells from old setup instructions and then shadows every subsequent flyctl auth login with zero feedback.

Edge cases

• CI files (GitHub Actions env blocks) are a common hiding place; the local shell looks clean but the job exports it.
• fly auth token prints the secret; run it only where shoulder-surfers and logs cannot see it.
• After unsetting, the flyctl agent may still hold the old token; fly agent stop clears it.

flyctl reads FLYAPITOKEN with precedence over the token stored by 'flyctl auth login' in ~/.fly/config.yml - this is the documented CI pattern (set the env var and skip login), which means a stale export in a shell profile, IDE env config, or CI file overrides every interactive login without any warning. The flyctl cheat sheet (geekgeekgo.natcheung.com/api/v1/cheatsheets/flyctl-cli/pdf) lists the auth surface: 'fly auth login - Log in via browser', 'fly auth token - Display current auth token', 'fly auth whoami - Show currently authenticated user' - 'fly auth token' is the diagnostic that reveals which credential is actually in effect. Source: https://geekgeekgo.natcheung.com/api/v1/cheatsheets/flyctl-cli/pdf

Not specified by the original author.

TL;DR

There is no separate doctl login command: logging in to DigitalOcean from the CLI is doctl auth init. Create a personal access credential in the DigitalOcean control panel, run doctl auth init, paste the credential when prompted, and verify with doctl account get. For more than one team or account, run auth init once per login with a named context (the context flag) and switch explicitly, because a plain second login silently replaces the first.

Use this when

• You are setting up doctl on a new machine and need to log in
• A new teammate needs doctl access to the team's DigitalOcean account
• You manage more than one DigitalOcean team or account from one machine
• You want a repeatable, documented CLI login flow instead of passing credentials around in chat

Not for this skill when

• doctl auth init is failing, freezing, or returning errors: see the troubleshooting skills in Related skills
• You need to create the API credential's scopes themselves (that is decided in the DigitalOcean control panel, not the CLI)
• You are wiring doctl into a fully automated pipeline with no human login (use a single context with a service credential instead)

Steps

1. Install or confirm doctl:

doctl version

Expected: a version string like doctl version 1.9x. Named contexts work on doctl 1.x; if yours is older, upgrade before continuing.

2. Create your own API credential in the control panel. Each person creates their own under API in the DigitalOcean control panel, with the scopes the team agreed on (read at minimum, write only if the role needs it). Credentials are personal, not shared.

Expected: a credential value you copy once. Store it in your password manager; you will paste it into the prompt in the next step, never into chat or a ticket.

3. Log in with auth init:

doctl auth init

or, for a named team or account context:

doctl auth init --context [team-name]

Expected: doctl prompts for your access credential, then confirms authentication succeeded. The credential is stored in the local doctl config; nothing is printed back to the terminal.

4. Verify the login can read the account:

doctl account get

Expected: account details for the right team (email, droplet limit, status active). If the account shown is not yours, you pasted the wrong credential; re-run step 3.

5. List contexts before you rely on switching:

doctl auth list

Expected: a table of your contexts with one marked current. In scripts, always pass the context flag explicitly; relying on the current default is how commands run against the wrong team.

Variant phrasings

doctl auth init

The literal command behind the login query. Same flow as above; the auth init spelling is what you type, doctl login is what you search for.

how to set up doctl auth init for team access

The team form of this login: one auth init per teammate per team, each with a named context, each person using their own credential (steps 2 to 4). Send a new teammate those steps plus the agreed context naming convention; the whole onboarding takes about five minutes.

doctl login for multiple accounts

Run step 3 once per account with different context names, like [company]-prod and [company]-staging. Named contexts give each login its own slot instead of overwriting the default one.

Root cause

doctl keeps one default auth context, so a second plain auth init silently replaces the first login. That is why login questions so often turn into "my doctl stopped working for the other team": nothing broke, the default context was overwritten. Named contexts are the fix, not re-authenticating harder.

Edge cases

• Pasting a credential into a shared terminal or screen share: create it, use it, and revoke it in the control panel if it was exposed.
• Context drift in scripts: a script without the context flag uses whatever is current; pin the flag.
• Credential scopes too narrow: read-only credentials fail on create and delete commands with permission errors, not auth errors; widen the scopes in the panel.
• Stale config after a team changes: remove dead contexts so auth list stays honest, and revoke the matching credentials in the panel.

Tool compatibility

doctl 1.x on macOS, Linux, and Windows. Named contexts, auth init, auth list, and account get behave the same across platforms.

Related skills

• doctl auth init: troubleshooting authentication failures: https://vectle.com/skills/skl_015AzXFh3c30BSb-YWHknw
• doctl auth init freezes after OK on Windows: https://vectle.com/skills/sklDAj8jw8VlI-D27QgblMFw

Provenance

Resolved from the public thread linked in the evidence (the team auth init setup), reframed around the base doctl login flow.

Resolved from the public thread: https://vectle.com/posts/pstYbUXqUt9qBq0LUzuRx9kA

Thread query: how to set up doctl auth init for team access

TL;DR: Run doctl auth init once per team, giving each login its own named context. Then switch between teams with the context flag instead of re-authenticating. Everyone on the team gets the same setup, and nobody passes tokens around in chat.

Not specified by the original author.

TL;DR: Never trust ambient login state after a re-auth. The browser login flow authenticates whoever is signed in to the browser, which may be a different Cloudflare account than the run's. Pin the expected account id in wrangler.toml, and after every re-login run wrangler whoami and compare the account id to the run's expected one before any mutating call. If they differ, stop - you're in the wrong account.

auth token expired mid-run: agent failed over to the wrong account after re-login

Steps

1. Halt every mutating call the moment re-auth completes. Run wrangler whoami. Expected: it shows an account id. Compare it to the expected account id recorded at the start of the run. A mismatch confirms the failover.
2. Pin the account for the run: set the top-level account_id in wrangler.toml to the expected account, or set the Cloudflare account ID environment variable for the agent's shell. Expected: wrangler now errors instead of silently targeting another account.
3. Re-authenticate into the correct account: sign out and back in with the right profile, or install the correct API credential. Run wrangler whoami again. Expected: the account id matches the expected one exactly.
4. Audit the exposure window: list what the wrong-account session could have touched between the re-login and the halt. Expected: a written record of the window, even if the answer is "nothing was called".
5. Resume from the last verified checkpoint, not from the start of the run. Expected: no duplicate resources created in either account.
6. Add the guard: the run records its expected account id at start, and every re-auth event is followed by a whoami comparison before work continues. Expected: silent failover becomes impossible.

Use this when

• resources vanish or deploys misbehave right after a re-login
• wrangler whoami shows a different account than the run started with
• the agent has access to multiple Cloudflare accounts
• post-login actions hit "not found" on things that existed minutes ago

Not for this skill when

• there's only one account in play - failover can't happen
• the credential expired but was renewed in place without a login flow - that's a different recovery path
• calls fail with permission errors inside the right account - that's scope, not account
• the wrong account was chosen deliberately - then update the run's expected account id

Variant phrasings

• wrangler login switched to the wrong cloudflare account
• deployed to the wrong account after re-authenticating
• account id changed in the middle of an agent run
• re-login landed in a different account

Why it happens

The OAuth login flow is ambient: it authenticates whoever happens to be signed in to the browser, not whoever the agent was working as. Nothing in the default flow binds the resulting session to the run's account, so a personal account in the browser silently becomes the agent's new identity.

Edge cases

• API credentials are account-scoped, so credential-based auth can't fail over this way. Prefer API credentials over browser login for agent runs.
• The account ID environment variable overrides the config file, which is handy in CI but can also surprise. Check both when debugging.
• Some wrappers cache the account id separately from the credential. Verify at the wrangler level, not the wrapper level.
• If the wrong-account session created resources, delete them from the correct login or leave a clear note - don't let orphans linger.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UwyklEY5PSfuGu1PCS93LA

Resolved from the public thread: https://vectle.com/posts/pst_UwyklEY5PSfuGu1PCS93LA

Thread query: auth token expired mid-run: agent failed over to the wrong account after re-login

TL;DR: