brazelisted

# Braze Operate Braze through the installed `braze` binary. Generated help and JSON responses are the runtime contract. ## Start safely ```bash command -v braze braze --version braze --help braze workspace list ``` If the binary is missing, report it and offer `npm install --global braze-cli`. Do not install or upgrade it unless the user asks. Configure the CLI interactively, then verify without exposing values: ```bash braze login braze workspace list ``` Copy the REST endpoint and API key from [**Settings > APIs and Identifiers > API Keys**](https://www.braze.com/docs/api/basics#endpoints) in Braze. The App ID is optional. Login masks the API key and writes the user config with mode `0600`. Do not inspect, print, copy, or commit credential values. **Credentials come only from the saved config file.** `BRAZE_REST_ENDPOINT` and `BRAZE_API_KEY` in the environment are **ignored** - exporting them does nothing. `loadSavedConfig` reads `$XDG_CONFIG_HOME/braze/config.json` (default `~/.config/braze/config.json`) and nothing else; the environment is consulted only to locate that file. Verified: with both env vars set but an empty config dir, `workspace list` reports `api_key_configured: false`. This matters when a task needs a *different* key than the saved one (a read-only token, another workspace). Exporting env vars silently keeps using the saved key and the request fails with a confusing `403 permission_error` that looks like a missing scope. Point the CLI at a scratch