Profiles

One machine, multiple Elven identities. Each profile stores its own credentials in your OS keyring (or a chmod-600 file on Unix as a fallback).

When you'd want this

• Personal + work accounts — managing both your hobby creator account and a publisher account from the same terminal.
• CI vs. local — separate creds for your laptop and your CI pipeline so revoking one doesn't kick the other out.
• Testing different scopes — e.g., a "limited" PAT and a "full" PAT side by side.

Commands

# Log into a named profile (creates it on first login)
elven login --profile work
elven login --profile personal --token el_pat_...

# List all stored profiles
elven profile list

# Switch the default profile (the one used when no --profile is passed)
elven profile use work

# Use a profile for a single command
elven --profile work listing mine

# Log out of one profile
elven --profile work logout

Storage layout

Credentials live in your OS's native keyring:

• macOS: Keychain Access → entries under the elven-cli service.
• Windows: Credential Manager → entries under elven-cli.
• Linux: GNOME Keyring or KWallet, via libsecret.

If keytar (the native module the CLI uses) can't initialize — common on bare Linux without libsecret-1-dev, or in some sandboxed CI runners — the CLI falls back to ~/.elven/credentials.json with chmod 600. Both paths are profile-aware.

In CI / Docker

Skip profiles entirely. Set ELVEN_TOKEN as an env var and the CLI uses it for every command without touching the keyring:

env:
  ELVEN_TOKEN: ${{ secrets.ELVEN_TOKEN }}

The env var takes precedence over any stored profile — useful for running against a different account temporarily without disturbing your local profiles.

Resolving the active profile

Precedence (highest first):

1. --profile <name> flag
2. The "current" profile (set by elven profile use <name>)
3. default

The whoami command always reports which profile it's using:

$ elven whoami
{
  "profile": "work",
  "userId": "22b8bd0e-...",
  ...
}