# 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: ```sh DISKO_TOKEN="$DISKO_TOKEN" npx disko publish --visibility public --json ``` On a workstation, store it in the OS credential store by piping it: ```sh npx disko login --with-token < token.txt ``` `DISKO_TOKEN` takes precedence over stored credentials. A command whose token lacks a needed permission fails with [`missing_permission`](/errors/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](/reference/cli#credentials).