Skip to content
Thyme Docs

thyme login

Authenticate the CLI to the selected Flow deployment. Standard login creates a personal credential for upload and permitted reads. --management requests a separate credential bound to one workspace, with management scopes shown during consent.

thyme login [--browserless] [--token] [--management] [--api-url <url>] [--rewrite-api-url]

Choose the deployment

For a development deployment, use its supplied HTTP API base URL:

export THYME_API_URL="$API_URL"
thyme api-url
thyme login

Set API_URL before this example. The CLI's built-in default is https://flow.thymelabs.io/http; that is not an automatic selection of your development deployment. Credentials and resources must belong to the deployment you target.

--api-url <url> accepts HTTP or HTTPS, uses that URL for this login, and persists it as apiUrl in ~/.thyme/config.json. Subsequent commands still give an exported THYME_API_URL precedence over saved config. --rewrite-api-url prompts to replace a saved URL; in CI, pass --api-url explicitly.

Browser and pairing flows

thyme login
thyme login --browserless

The default flow opens the approval URL returned by the API. The browserless flow prints a verification URL and pairing code to approve from another device. Both poll for approval every two seconds for up to five minutes.

The default browser flow requires an interactive terminal. On a headless machine, use --browserless or an existing key. Browserless approval still requires a person; it is not an unattended CI credential exchange.

Workspace management access

thyme login --management
# From a headless machine:
thyme login --management --browserless

An owner/admin selects a workspace and approves the listed scopes in the Console. The CLI saves the workspace-bound credential alongside other workspace credentials. Management commands select a sole eligible credential automatically, or require --workspace when several workspaces are available.

A matching workspace credential can also authenticate thyme upload --workspace WORKSPACE_ID. --management cannot be combined with --token; management consent uses the browser or pairing flow.

Existing API keys

Create a key in your deployment's Console → API Keys, then use:

thyme login --token

On a terminal, the CLI prompts for the key. Without a terminal it reads stdin:

printf '%s\n' "$THYME_API_KEY" | thyme login --token

The CLI rejects empty or very short tokens, then verifies the key against the API. It saves a verified management credential in the credential list when the API identifies it as one; other keys use authToken.

For unattended pipelines, supply an appropriately scoped key as THYME_AUTH_TOKEN and skip login. Stored credentials take precedence over that environment variable, so use a clean runner. See CI use.

Credential storage and revocation

Login writes ~/.thyme/config.json with file mode 0600, not a project .env. Standard tokens use authToken; workspace credentials use the version-2 credentials array.

thyme logout removes local credentials only. Revoke the key in the Console to invalidate it on other machines. Deleting local configuration does not unset exported environment variables.

Authentication endpoints

EndpointPurpose
POST /api/cli/auth/startStart standard or management browser/pairing consent.
GET /api/cli/auth/pollPoll the session using its ID and secret.
GET /api/auth/verifyVerify the resulting key and discover authorized workspaces/projects.

These endpoints are relative to the configured HTTP API base. See authentication and configuration.