`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`.

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

## Fix

1. Check for the override:
   ```bash
   env | grep FLY_
   ```
   Expected culprit: `FLY_API_TOKEN` set to an old or different account's token.

2. See which credential is actually active:
   ```bash
   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:
   ```bash
   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.