A token does not inherit the roles of the person who issued it. It carries a derived role, cli, decided by the server.

That makes it deny-by-default. A permission written for user does not match an account whose only role is cli, so a token reaches only what has been granted to it deliberately. Getting the grants wrong yields a token that cannot do enough — never one that can do too much.

In practice a token can read the plugin catalog, read and change plugin configuration, run GraphQL queries, mint a service admin token for a service you own, and provision a free service. It cannot start a Stripe Checkout session, cancel a subscription, read invoices, change your account, or manage your team.

Give the token a name and an expiry, and copy it — the clear value is shown once and never again. Only a hash is stored, so a leaked database is not a leak of every token, and a lost token is revoked and reissued rather than recovered.

The default expiry is 90 days. Not "never": a token that does not expire is a token nobody revokes.

The listing shows each token’s name, when it was created, when it expires, and when it was last used. That last column is the one that earns its place — the question is rarely "which tokens exist" but "which of these six have I forgotten about".

Revoking takes effect within about a minute, the lifetime of the authenticator’s cache.

Removing you from a team disables your tokens against that team’s services at once, without revoking anything — membership is read live, not frozen into the token when it was issued.

For the same reason a token cannot pick a team on your behalf: an operation that needs one names it. rhc new free --org <id> is explicit at the point of call rather than implicit in the credential.

See The rhc command line. In a pipeline, set RH_CLOUD_TOKEN from your platform’s secret store; in a terminal, rhc login stores it at ~/.config/restheart/session.json, readable only by you.