`scrydon` CLI

The Scrydon developer CLI authenticates your machine against a Scrydon installation. Once you are logged in, tools that talk to the platform can use the stored token instead of asking you for credentials.

Install

Run it without installing:

bunx @scrydon/cli login https://app.example.com

Or install it so scrydon is on your PATH:

bun add -g @scrydon/cli
# or: npm install -g @scrydon/cli
scrydon login https://app.example.com

Logging in

scrydon login uses the OAuth device authorization flow (RFC 8628) — the same pattern as gh auth login. The CLI prints a URL and a code; you approve the request in your browser, and the CLI stores the resulting token.

$ scrydon login https://app.example.com
Logging in to https://app.example.com...

Open this URL in your browser to approve the login request:
  https://app.example.com/device?user_code=ABCD-1234

Or enter code ABCD-1234 at:
  https://app.example.com/device

Waiting for approval (expires in 300s)...

Login successful. Credentials saved to ~/.scrydon/credentials.json

Tokens are written to ~/.scrydon/credentials.json with mode 0600, keyed by installation URL. You can be logged in to several installations at once.

If your installation serves Better Auth somewhere other than /api/auth, pass --auth-base:

scrydon login https://app.example.com --auth-base /auth

Checking and clearing your session

scrydon whoami                        # which installations are logged in
scrydon logout https://app.example.com  # forget one
scrydon logout                          # forget all of them

scrydon whoami reads local state only. It reports which installations have a stored token — it does not contact the server, so it cannot tell you whether a token is still valid, expired, or revoked.

CI and scripted environments

A pipeline should not run the plain scrydon login above — that flow authenticates a person through a browser, which a pipeline does not have. Two options, for two different kinds of caller:

A pipeline authenticating as its own machine identity (the common case): scrydon login <url> --service-account <client-id> --service-account-secret <secret> [--ttl <duration>]. This exchanges a durable client id and secret — from Settings → Service accounts — for a short-lived bearer, no browser involved, and stores it the same way the device flow does. See AI Gateway → For pipelines for a worked CI example.
A script run under a person's own identity (for example a one-off maintenance script a developer runs locally with their own access, not a scheduled pipeline): set SCRYDON_API_KEY to a Personal Access Token instead.

export SCRYDON_API_KEY="scy_..."

SCRYDON_API_KEY takes precedence over every stored credential, including one saved by --service-account. Because it names a token but not a host, it cannot tell tooling which installation to talk to — supply the URL explicitly wherever one is required. scrydon whoami warns you when the variable is set so a wrong-account problem does not send you hunting through the credentials file.

Authoring packs and integrations

Building packs, integrations, workflows, or process flows is a separate CLI with a much larger dependency footprint:

bunx @scrydon/sdk-authoring --help

See Authoring. It reuses the same login and the same credentials file, so scrydon login covers both.

CLI