Repository navigation
Stage-1: Auth storage v2 and token resolution (no UX change) #1383
Description
Note
TL;DR — The auth layer holds one account and cannot tell where a token came from. Three resolvers disagree about which token wins, auth.json is a flat blob for a single user, and the keyring uses one fixed name per secret. This stage rewrites all three so the storage can hold N accounts. Nothing changes for users — no new flags, no new commands. Three subtasks, each releasable on its own.
Part of #1297. Comes after Stage-0 (#1387), and everything later depends on it.
Subtasks
| # | Issue | What |
|---|---|---|
| 1 | #1418 | Token resolution — one resolver, one precedence order, only login persists |
| 2 | #1419 | auth.json v2 — profiles keyed by user ID, with migration |
| 3 | #1420 | Secret storage v2 — per-profile keys in the keyring and the file backend |
Order is fixed. 2 needs 1's read/write split; 3 needs the user IDs from 2.
Decisions already made
- Precedence is
--token→APIFY_TOKEN→ stored. It is whatmcp installand theactorentrypoint already do; onlyresolveTokendiffers. APIFY_TOKENkeeps working. Removing it would break CI, agent harnesses and every Actor run.apify loginignoresAPIFY_TOKEN. Logging in is explicit.- Only
apify loginwrites credentials.--tokenandAPIFY_TOKENare one-off. - Profiles are keyed by
userId, not by a display name, so a rename cannot orphan a secret. - The XDG config directory move is not part of this. Nobody outside Apify has asked, and two migrations in one release is how you get a bug nobody can reproduce.
Not in scope
No additive login, no --profile, no auth switch, no auth list. The file can hold N profiles; only Stage-2 (#1386) puts a second one there. Users see no difference after this stage.
Compatibility
After #1419 an older CLI is partly incompatible with the new file, verified against 1.10.0. Commands that call the API first still work, because the per-command refresh re-adds the flat id/username. apify run throws Stale credentials found without user metadata, because it reads the file without that refresh. apify login merges rather than replaces, so it leaves activeProfile on the old account while the token becomes the new one. Needs a changelog note: run apify login again after upgrading. There is no backup file — one was tried and dropped, since nothing read it and it could not restore a login.
🤖 Generated with Claude Code
Activity
[-]Refactor secret storages[/-][+]Stage-3: Refactor secret storages[/+][-]Stage-3: Refactor secret storages[/-][+]Stage-1: Refactor secret storages[/+]patrikbraborec commentedon Sep 8, 2026
Folding #567 in here. Its proposal: replace the flat
auth.jsonwith a keyed structure (Record<UserId, Data>or an array of entries) that holds 0..n accounts, and store only what the CLI needs (token mandatory, username maybe, profile/email/plan fetched on demand). Per @vladfrangu it must be adapted to the keyring setup.[-]Stage-1: Refactor secret storages[/-][+]Stage-1: Auth storage v2 (multi-profile capable, no UX change)[/+][-]Stage-1: Auth storage v2 (multi-profile capable, no UX change)[/-][+]Stage-1: Auth storage v2 [/+][-]Stage-1: Auth storage v2 [/-][+]Stage-1: Auth storage v2 and token resolution[/+][-]Stage-1: Auth storage v2 and token resolution[/-][+]Stage-1: Auth storage v2 and token resolution (no UX change)[/+]feat: auth.json v2 with profiles keyed by user ID (#1434)
feat: key secrets by user ID on both backends (#1450)