What version of the CLI are you using?

Locally I'm using 4.37.2 which I installed maybe a month and a half ago through brew, in CI I'm using npm i -g @railway/cli which I expect to be whatever the latest version is.

Edit: I just upgraded through brew to 5.6.2 and it's still not working locally with a freshly minted token.

Your account is active and your approach is correct per our docs, so the token should work. Two things to rule out: first, make sure RAILWAY_TOKEN is not also set in your shell environment (setting both causes an error), and second, run railway logout before retrying to clear any cached session that may conflict with the env var. If it still fails after both of those, try hitting the API directly with curl using the same token in an Authorization: Bearer header to isolate whether the issue is CLI-specific.

It does not work. Hitting the API directly with curl yields the same result. There is no RAILWAY_TOKEN or RAILWAY_API_TOKEN set locally. Please try yourself to mint an API token scoped to a project and see if it works.

An unscoped token still gives an unauthorized error when running RAILWAY_API_TOKEN=<TOKEN> railway whoami?

Yes, whenever I make a new railway token scoped to our project and then if I use the command I get unauthorized. Here's an example I just did (I've already revoked the token):

bo@local ~ % railway whoami
Unauthorized. Please login with `railway login`
bo@local ~ % RAILWAY_API_TOKEN=f20ad28c-ae92-4bd9-9951-00632fac749a railway whoami
Unauthorized. Please check that your RAILWAY_API_TOKEN is valid and has access to the resource you're trying to use.
bo@local ~ % railway --version
railway 5.20.0
bo@local ~ % 

Can you try using an unscoped token? IIRC RAILWAY_API_TOKEN shouldn't be scoped.

If you're using a token that's scoped to a project, it should be RAILWAY_TOKEN.

Also, scoped tokens do not have access to user methods (eg, whoami).

Unscoped tokens work fine but I need the tokens to be scoped to a specific project for ACL reasons. This doc page says that there are per-workspace-level tokens: https://docs.railway.com/integrations/api#choosing-a-token-type. RAILWAY_TOKEN is documented as only having access to a specific environment in a specific workspace so it's not helpful for CI actions that involve workspace-level changes like creating/destroying environments. If it's intended to ONLY have universe-scoped and environment-scoped tokens then these docs need to be updated. But really, having scoped tokens is important for ACL and feels like a basic requirement.

Also, the unscoped RAILWAY_API_TOKEN does have access to whoami so shouldn't the workspace-level token also? They're both user account tokens anyways right? For example, this is the output with an unscoped token:

bo@local ~ % RAILWAY_API_TOKEN=4a60d87e-5433-455a-abd7-4d921ddc511f railway whoami
Logged in as Bo ([my work email]) 👋

so I would expect this to work the same with a scoped token.

Again, scoped tokens do not have access to user methods.