The CLI authenticates against the Salesprompter app backend and stores the result locally. This page documents the runtime behavior around that contract.
Login modes
Device login
Recommended when the app exposes:
POST /api/cli/auth/device/startPOST /api/cli/auth/device/poll
Command:
node ./dist/cli.js auth:login
The CLI prints the verification URL and user code immediately, then opens the browser when the terminal session allows it.
Optional overrides:
node ./dist/cli.js auth:login --api-url https://app.salesprompter.com --timeout-seconds 180
Direct token login
Use this as the fallback when the app issues a CLI token directly:
node ./dist/cli.js auth:login --token "<token-from-app>"
The CLI verifies the token through GET /api/cli/auth/me before it stores the session.
Session file
By default the CLI stores the session here:
~/.config/salesprompter/auth-session.json
Stored fields:
{
"accessToken": "token",
"refreshToken": "optional-refresh-token",
"apiBaseUrl": "https://app.salesprompter.com",
"user": {
"id": "usr_123",
"email": "user@example.com",
"name": "Example User"
},
"expiresAt": "2026-03-10T12:00:00.000Z",
"createdAt": "2026-03-10T09:00:00.000Z"
}
Environment variables
| Variable | Purpose |
|---|---|
SALESPROMPTER_API_BASE_URL |
override the backend URL |
SALESPROMPTER_CONFIG_DIR |
override the local config directory |
SALESPROMPTER_SKIP_AUTH=1 |
bypass the auth guard for tests and local development only |
Runtime behavior
- non-auth commands require a valid local session
- expired sessions fail before command execution
auth:whoami --verifyround-trips to the backendauth:logoutremoves the local session file
Failure mode when device flow is unavailable
If the backend does not expose device login, the CLI raises a runtime error that points users toward token-based login. That is the intended fallback behavior.
The app should therefore make it straightforward to issue a CLI token through the app UI or API when device flow is disabled.