CLI unauthorized on all commands despite successful fly auth login

Questions / Help
,
1

CLI unauthorized on all commands despite successful fly auth login

Hi all — running into a strange auth issue and hoping someone has seen this before.

Setup:

  • macOS, flyctl 0.4.29
  • App: pauls-crm (personal org)
  • Free plan

Problem:
fly auth login completes successfully and fly auth whoami returns the correct email. But every other CLI command fails with unauthorized:

fly orgs list
→ Not authorized to access this organization

flyctl deploy -a pauls-crm
→ unauthorized

fly machine start -a pauls-crm
→ unauthorized

What I’ve tried:

  • Full logout/login cycle (fly auth logout && fly auth login)
  • Fresh terminal session
  • fly tokens create deploy -a pauls-crm → also unauthorized

What works:

  • Dashboard at fly.io works fine — I can see and start the machine there
  • App is currently running (started via dashboard)

Trace ID: 140d3e51aa1e1be1894a035289541ba4

Any ideas? Is this a token scope issue or something on the platform side?

Thanks

2

Hm… I’ve seen puzzling unauthorized errors recently that turned out to be due to local clock drift, although I’m not sure it would cause exactly the pattern reported above.

I would check the shell’s environment variables for ones beginning with FLY_, too. It’s unusual for those to persist across terminal sessions, but perhaps you have some set in .bashrc (or equivalent).

I believe it’s also possible to create a token from the dashboard (i.e., without going through fly tokens create). You can then try setting that as FLY_API_TOKEN:

When this variable is set, flyctl skips all interactive auth prompts and uses the token for every command. It takes precedence over any credentials from a prior fly auth login.

Once you have that in your environment, you can use fly tokens debug to get a dump of what’s actually being authorized by it. Those are a little difficult to interpret, but it will help determine problems with validity windows (expirations), for example, and people have had surprises with those in the past.

Don’t post the output of fly tokens debug, by the way, :dragon:, since doing so might plausibly leak private keys, or the like. I would err on the safe side.

Finally, you’re somewhat behind on flyctl versions, so it might be prudent to investigate why that happened (assuming it wasn’t intentional). There was at least one intervening flyctl commit that mentioned auth in some way.

Hope this helps a little!