pure login

pure login [options]

Asks how you want to log in, then verifies the key against api.pure.dev and saves it — see Where the key is stored below.

How do you want to log in?
  1) Enter an existing API key
  2) Generate a new API key (opens your browser)
>

Option 1: enter an existing key

Prompts for a key (input is masked, like a password prompt) and verifies it. Use this if you already have a key from the dashboard or a teammate.

Option 2: generate a new key

1. Prompts for a name for the key — press Enter to accept the default, CLI Login - <hostname> - <date> (so keys from different machines are easy to tell apart in the dashboard’s API Keys list).
2. Starts a small HTTP server on your machine, on a random port, and opens your default browser to the Pure dashboard.
3. You sign in (if you aren’t already) and click Authorize.
4. The dashboard creates the key — scoped to compile access only, named whatever you entered in step 1 — and hands it back to the local server step 2 started.

If the browser doesn’t open automatically, copy the URL pure login prints and open it yourself.

SSH, remote, and container sessions

If the browser can’t reach the local server option 2 started — because they’re on different machines, which is the common case over SSH, in a container, or in a remote dev environment — the dashboard page still shows the newly created key on-screen instead of silently failing. Copy it, then run:

pure login --paste

This skips the menu and goes straight to option 1 (prompt for an existing key) — paste the key you just copied.

Options

| Flag | Description | |---|---| | --api-key <key> | Skip the menu entirely — use this key directly | | --paste | Skip the menu, prompt for an existing key directly (same as choosing option 1) | | --api-url <url> | API endpoint (default: wss://api.pure.dev/ws) | | --app-url <url> | Dashboard URL for option 2’s browser flow (default: derived from --api-url, e.g. https://app.pure.dev) |

$PURE_API_KEY works the same as --api-key. $PURE_APP_URL works the same as --app-url.

CI and headless environments

pure login’s browser flow requires an interactive terminal. In CI, skip it entirely.

GitLab CI: authenticate with a short-lived id_token GitLab mints per-job instead of a stored API key — see Authentication → OIDC. No secret to create, rotate, or leak:

compile:
  id_tokens:
    PURE_ID_TOKEN:
      aud: https://api.pure.dev
  script:
    - pure build src/main.ts \
        --oidc-token "$PURE_ID_TOKEN" --account <your-account-id> --org <your-org-id>

--account/--org (shown on the connection’s row on the Integrations page) are required alongside --oidc-token — see Authentication → OIDC for why.

Any other CI provider: create a key from the dashboard (see Guide → API keys) and pass it via the PURE_API_KEY environment variable:

PURE_API_KEY=pk_live_... pure build src/main.ts

No pure login call is needed when PURE_API_KEY or PURE_OIDC_TOKEN is set — every command reads it directly.

Where the key is stored

pure login stores the key in your OS’s credential store when one is available:

• macOS: the Keychain, via the built-in security command.
• Linux: the system keyring, via secret-tool (part of libsecret) — common on desktop distros, not universal on servers/minimal installs.
• Windows, or when no keychain is available: ~/.config/pure/credentials (mode 0600), the same file-based fallback Claude Code itself uses when its own Keychain write fails.

Set PURE_NO_KEYCHAIN=1 to always use the file, skipping the keychain attempt entirely.

Logging out

pure logout

Removes the stored key from wherever it’s actually kept — the OS keychain and/or the credentials file.