reliant project list, reliant workflow run and reliant forge … use when you type them. An API token does the same job for a script or CI runner, without a browser. A daemon credential belongs to a machine: it lets a daemon connect and serve your agents, and nothing else. All three are rlat_… access tokens that act as you, and all three can be revoked.
Sign in on your own computer
reliant:api to use Reliant as you, and the deploy, secret and domain permissions that Forge needs. You only get the deploy, secret and domain permissions your organization grants you. Because they are part of the one login, Forge needs no login of its own.
Logging in again from the same computer replaces that computer’s previous login token rather than adding another.
Check who you are signed in as
reliant auth status reads only local files and makes no network call, so it is quick and safe to put in scripts. It exits 0 when a credential is available for the server, and 1 when there is none:
--json for a machine-readable answer:
RELIANT_TOKEN is set, status reports that it will use it (Using the token in RELIANT_TOKEN). Because status never contacts the server, it does not check that the token is valid. The first real command does that, and its error names the credential it tried:
Sign out
reliant auth logout removes this server’s login from the credentials file and forgets any Forge tokens exchanged from it. Two things are unchanged. The token itself stays valid on the server until it expires or you revoke it (see below). And a running daemon keeps working, because it uses its own daemon credential.
Sign in where there is no browser
reliant auth login finishes by redirecting your browser to 127.0.0.1 on the computer running the CLI. On a server you reach over SSH, or on a CI runner, there is no browser on that computer, so the redirect has nowhere to land. Don’t try to log in there. Create a token on a computer that has a browser and take it to the one that doesn’t.
To run commands (workflow run, project list, trigger …) on the headless machine, create an API token on your own computer:
login. The token is printed once and not stored, and your own login is untouched. On the headless machine, provide it as RELIANT_TOKEN:
create again with the same --name replaces that token, so rotating a token is one command.
To run a daemon on the headless machine, use a daemon credential instead. Create one in the app under Settings → Access Tokens and pipe it in:
List and revoke API tokens
reliant auth token list shows your API tokens: name, ID, prefix, when each was created and last used, when it expires, and whether it is still active. It never shows the secret. reliant auth token revoke <name-or-id> revokes one. If two tokens share a name, the command refuses to guess and asks for the ID. Both commands use your current credential, so they work with RELIANT_TOKEN as well as with a login. Daemon credentials are listed and revoked in the app, under Settings → Access Tokens.
Connecting Claude, Codex or Antigravity from the web app
Signing in to Claude Code, Codex or Antigravity ends with the provider redirecting your browser tolocalhost, so something on the computer your browser runs on has to catch that redirect. The desktop app does this for you, and so does a daemon running on that same computer. If you use the web app and the chat’s machine is somewhere else (a cloud machine, a remote server), run the helper in a terminal on your own computer and leave it running while you connect:
Related topics
- Scripting and CI: using
RELIANT_TOKENin automation - Run a machine from the terminal
- Forge sign-in: how your session becomes a short-lived deploy token
- CLI reference:
reliant auth