[Pijukatel]

• A new token that resolves to an account the runtime already knows joins that user instead of replacing its record.
• The user's earlier tokens keep resolving, so a run container or a restart does not lose the account after the CLI's OAuth login rotates its token.
• token stays the latest one for new runs, schedules and standby links; the last 100 tokens are kept.
• The upstream fallback still relays exactly the token the caller sent, never the user's latest one.

[apify-service-account]

Platform parity:

• When the upstream fallback relays a request made with one of a user's earlier tokens, it sends the user's latest-seen token instead (req.user.token is now the shared record's newest token). So a request with a valid personal token can fail closed because the latest token was an expired OAuth one, and a request with an expired or scoped token can succeed with another token's rights. The platform authenticates, scopes and expires each request by the exact token it receives. api.md says the opposite ("always the exact bearer token the caller themselves sent") — users.ts#L58-L74 · api-fallback.ts#L189 · api_authentication.middleware.ts#L82-L114

Reviewed commit: 01e8369

[Pijukatel]

Fixed in 1083a2a: auth() now keeps the presented token on the request, and the upstream fallback relays that one instead of req.user.token. A new test covers a user with two tokens calling with the earlier one.

---

Generated by Claude Code

[apify-service-account]

Platform parity: Aligned.

Reviewed commit: 1083a2a