Skip to content

Distinguish access-token expiry from renewable CLI sign-in lifetime #199

Description

@adrianwebb

Objective

Follow-up to Deployment #716 / Platform #501: CLI now has a managed24h refresh-session policy with300s access tokens. The auth login human renderer currently labels result.expiresAt as Session expires, although auth.ts computes it from token expires_in. This misstates renewable session lifetime.

Contract and acceptance

Use an unambiguous access-token-expiry/automatic-renewal label. Do not invent a24h expiry from the local clock or persist plaintext tokens; only report an actual session deadline if authoritative Identity data supplies it. Test human/JSON semantics and keep401/revocation diagnostics accurate. User asked for fewer interactive logins; short-lived token renewal is intended.

Evidence

CLI staging e2fd62f, src/cli/support/human-renderer.ts line122 and src/cli/commands/auth.ts token lifetime calculation. Deployment rc304 installed policy read-back86400s/300s. No functional blocker to24h renewal; include label fix in next CLI RC instead of rebuilding the just-accepted unchanged CLI artifact solely for copy.

Rollback

Display-only change; no session-storage migration. Issue→PR→Actions→staging→next candidate. No routine comments.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions