fix(auth): honor APIFY_TOKEN env var over stored login token

[l2ysho]

Problem

• APIFY_TOKEN=<token> apify run failed with Insufficient permissions for the Actor run.
• APIFY_TOKEN=<token> apify actors ls listed Actors from the logged-in account, not from the token's account.
• Cause: the CLI used the token from apify login and ignored APIFY_TOKEN.

What changed

Token order is now the same everywhere: --token → APIFY_TOKEN → stored login.

• resolveToken now checks APIFY_TOKEN. This one spot covers ~50 commands.
• apify run no longer overwrites an inherited APIFY_TOKEN when it builds the Actor's env.
• APIFY_TOKEN and --token are one-time now. They are no longer saved over your apify login. Only apify login saves.
• username and id also come from the APIFY_TOKEN account. Before, commands used a token from one account and a name from another, and sent undefined/<actor> in CI with no login.
• apify auth token prints the token that is really used.
• Renamed getApifyTokenFromEnvOrAuthFile to getApifyToken.

Good to know

• A bad token fails on 401, 403 and 409. Other errors (offline, API down) skip the identity lookup instead, so apify run keeps working without network.
• Commands other than apify login no longer refresh username and id in auth.json. They update on the next login.

Tests

• Token order, and that APIFY_TOKEN does not overwrite the stored login.
• Identity comes from the APIFY_TOKEN account. 401/403/409 throw, other errors degrade.
• [api]: apify run passes an inherited APIFY_TOKEN to the Actor.

Follow-up

• getLoggedClient is named as a getter but also writes. Split is left for a separate PR.

🤖 Generated with Claude Code

[DaveHanns]

APIFY_TOKEN now silently overwrites the stored apify login credentials

The read-side precedence added here is correct, but this line has a downstream side effect that I think makes it a blocker.

Because resolveToken() now returns process.env.APIFY_TOKEN, getLoggedClient(), reached by ~all authenticated commands via getLoggedClientOrThrow(), then persists it:

// src/lib/utils.ts, getLoggedClient()
const resolvedToken = await resolveToken(token);          // ← now the APIFY_TOKEN value
…
if (apifyClient.token) {
    await setToken(apifyClient.token, { skipIfUnchanged: true });   // ← writes it to keyring/auth.json
}
…
writeFileSync(AUTH_FILE_PATH(), JSON.stringify({ ...existingFile, ...userInfo }));  // ← rewrites username/id too

setToken(…, { skipIfUnchanged: true }) writes whenever the value differs from what's stored. Pre-PR, resolvedToken was always the stored token, so this was a no-op. Now:

apify login --token <A>   # stored login = account A
export APIFY_TOKEN=<B>    # a different, valid token
apify actors ls           # reads B (correct) — but setToken overwrites stored A with B,
                          #   and auth.json username/id are rewritten to account B
unset APIFY_TOKEN
apify actors ls           # resolveToken → getToken() → returns B  ← login A is gone

So a transient env var permanently mutates the durable login: the apify login account is silently replaced, and the change persists after unset. Two consequences:

1. The env and stored tiers stop being independent — using APIFY_TOKEN destroys the stored login. This also contradicts the intent of the new run.ts guard's own comment ("must win over the stored login", i.e. without replacing it).
2. It re-triggers the macOS Keychain write prompt that skipIfUnchanged was added to avoid — every command run with a differing APIFY_TOKEN rewrites the keyring.

Suggested fix: in getLoggedClient, only call setToken / setProxyPassword when the token came from an explicit apify login, not when it originated from APIFY_TOKEN or --token flag of command other than apify login (the --token on other commands should be one-time overwrite as well), mirroring the guard already added in run.ts:332.

(Heads-up: if you make this change, apify auth token will then print the stored token while other commands use the env token — it reads getLocalUserInfo().token directly and only looks correct today because of this overwrite. It'd need to become env-aware too.)

🤖 Generated with Claude Code

[l2ysho]

you, this is a good catch and I am wondering how I missed this when I self reviewed 🤔

[l2ysho]

also I am inspecting getLoggedClient() and there are few things I really do not like (for example it is doing mutations but name suggests it is only get), I will create a follow up issue if I find it is worth of it.

[DaveHanns]

BTW, noticed the stale name of getApifyTokenFromEnvOrAuthFile. It no longer gets the token just from Auth file, but by default from keyring. We should simplify and correct the name.

[DaveHanns]

One possible blocker, otherwise looks good 🚀

[l2ysho]

@vladfrangu I really want to know what is your opinion about resolveToken function. There are multiple scenarios (APIFY_TOKEN, --token, normal auth, tests) and when I fix one I break some other. On a first look It feelslike good candidate for a deep refactoring. WDYT?