CLI tokens & CI
Publish from CI and agents with CLI tokens instead of a browser sign-in.
Normally disko signs you in through your browser. That doesn't work where
there's no person and no browser, such as a CI job that publishes on every
merge, or a coding agent. For those, use a CLI token: a secret string
that signs disko in on its own.
A token can only do what you allow when you create it, so a leaked CI token can't do more harm than its job needs. Create one in the Creator Portal under CLI tokens.
Permissions
Pick at least one permission when you create the token; they cannot be changed afterwards.
| Permission | Allows |
|---|---|
| Publish one game | publishing releases of that game |
| Publish all games | publishing to any game the account owns, now or later |
| Test rooms | creating test rooms, so disko dev works with the token |
No token can create games, deprecate releases, manage grants or tokens, or read private releases; those need the Creator Portal. Expiry is optional: none, or 1–365 days. The Creator Portal shows each token's expiry and last use, and any token can be revoked. The token is shown once.
Using a token
Tokens start with dpt_. They are never accepted as command-line arguments,
because arguments are visible in process lists.
In CI, set DISKO_TOKEN from a secret:
On a workstation, store it in the OS credential store by piping it:
DISKO_TOKEN takes precedence over stored credentials. A command whose token
lacks a needed permission fails with
missing_permission and exit code 3, names the
permission, and does not fall back to a browser sign-in. disko logout
deletes the stored credential.
See CLI commands.