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!

4

Update: fly auth token outputs a malformed token with a duplicated
prefix and space: “FlyV1fm2_FlyV1 fm2_…” — looks like a platform-side
token generation bug. Setting FLY_API_TOKEN with this value still fails.

5

Hi Paul, could you please try update flyctl to the latest version to see if that irons out any of the bumps you’re hitting?

6

Hi Paul, one more thing - setting FLY_API_TOKEN and being logged in via fly auth login tend to clash with each other. You can try:

  1. make sure there is not FLY_API_TOKEN set in the environment ( unset FLY_API_TOKEN in most shells), then fly auth logout and fly auth login again. Then check whether you can list organizations, for example.
  2. Once you can get the list of orgs, you can fly auth token . Set that as FLY_API_TOKEN, then fly auth logout (important) and try to do operations (list orgs etc). This should work the same as if you were logged in.