flyctl uses the wrong account: FLY_API_TOKEN overrides fly auth login

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.