Skip to main content
breeze login starts a short browser login flow. After you authorize the device, Breeze creates or rotates a key named breeze-cli/<host> and returns the plaintext key to the CLI once. Server-side API key storage remains hash-only. Login uses the selected profile’s API base URL, so environment-specific profiles authenticate against the matching Breeze account environment.

​
Log in

Login waits for you to approve the device in the browser. When you do not pass --timeout, the CLI uses a minimum wait so there is time to complete the browser step. An explicit --timeout value is honored as given. If the authorization link expires before you approve it, login stops with a clear “link expired” message. Run breeze login again to start a fresh authorization.

​
Log out

Logout removes the saved local key from the selected profile. It does not delete or revoke keys from your Breeze account.

​
How the CLI resolves credentials

For each invocation the API key is resolved in this order:
  1. --api-key flag.
  2. BREEZE_API_KEY, when BREEZE_CLI_PREFER_ENV_CONFIG=1 is set.
  3. The active ~/.breeze profile.
  4. BREEZE_API_KEY as a compatibility fallback.
The base URL follows the same pattern: explicit --base-url, then the env-preferred BREEZE_BASE_URL, then the active profile, then https://api.breeze.blue. breeze diagnostics --agent reports which source each value came from, which is the fastest way to debug an unexpected 401.

​
Where credentials live

  • Profile settings are stored in ~/.breeze/config.toml; keys are stored separately in ~/.breeze/credentials.json with 0600 permissions.
  • Output only ever shows masked keys — config show, diagnostics, and whoami never print the plaintext.
  • Installing and updating the CLI never require an API key.

​
Scripts and CI

Non-browser environments can provide credentials explicitly. Prefer stdin when writing a key into a local profile.