FileTokenStorage

On-disk token file path for this server.

Return the stored OAuthToken, or None if none is persisted.

Persist tokens to disk, preserving any stored client info.

Also records the absolute Unix-epoch expiry as a sidecar so a cold-started provider can detect a stale access token and trigger the SDK's refresh_token grant instead of a full browser re-auth. Cleared when expires_in is absent so the sidecar can't go stale.

Return the stored client registration, or None if none is persisted.

Persist client_info to disk, preserving any stored tokens.

Return stored public OAuth authorization metadata, if available.

Persist public OAuth authorization metadata beside the token state.

Persist tokens and client info in a single atomic write.

Prevents the state where one call succeeds and the other fails, leaving an orphan on disk.

Return the stored absolute token expiry (Unix epoch), or None.

Returns None for token files written before this field existed, for tokens whose provider omitted expires_in, or when the sidecar value fails to coerce to float. Callers should treat None as "expiry unknown" and decide policy (skip, assume-expired, etc.).

Return the stored loopback redirect URI port, if one is reusable.

DCR registers client_id against a specific redirect_uri. If the callback server binds a fresh random port on a later launch, the authorize request will carry a redirect_uri that no longer matches the one registered with the persisted client_id, and the authorization server will reject it ("invalid or missing redirect_uri"). Reusing the persisted port keeps the registration valid across runs.

Drop a persisted client registration that can't serve loopback login.

stored_loopback_port explains why the authorize request's redirect_uri must match the one registered against the persisted client_id. When that registered URI is not a reusable loopback callback (e.g. a portless http://localhost/callback left by an earlier non-loopback login), no port can be reused, so a CLI login binds a fresh random port and the server rejects the mismatched redirect_uri ("invalid or missing redirect_uri"). Removing the stale client_info makes the SDK perform a fresh DCR with the loopback redirect URI it will actually use.

Only discards when no token is persisted at all, so a session with a usable (or refreshable) token is never downgraded to a full re-auth. The presence check is deliberately conservative: it errs toward keeping the registration, never toward deleting one that might still be needed.