sz login
Scheduler Zero CLI login: sign in in a browser or save an api key. Usage, options, examples, output and authorization.
# sz login
The `sz login` command is part of the [Scheduler Zero CLI](/cli). Alias for auth login. When no key is available, creates a ten-minute browser-consent request, prints a matching confirmation code and waits using outbound polling. Opening the URL does not approve access; the signed-in human selects the organization, workspaces and permissions and explicitly approves or cancels. There is no localhost listener. With an explicit, environment or saved key, validates that key instead of starting new browser consent. Successful login saves the credential and an optional single-workspace default.
## Usage
```bash
sz login [options]
```
If you have not installed `sz` globally, replace `sz` in the usage above with `npx --yes @scheduler-zero/sz@latest` or `bunx @scheduler-zero/sz@latest`, preserving the arguments and options. See [installation](/cli/installation).
## Options
| Option | Meaning |
| --- | --- |
| `--api-key <key>` | API key (prefer SCHEDULER_ZERO_API_KEY) |
| `--base-url <url>` | API origin (default: https://api.schedulerzero.com) |
| `--workspace <id>` | Workspace id for workspace-scoped commands |
| `--no-browser` | Print the login URL without opening a browser |
| `--json` | Emit machine-readable JSON |
| `--format table\|json` | Select output format |
| `-h, --help` | Show this help |
## Examples
The UUIDs below are illustrative; use IDs from your own visible workspaces and campaigns.
```bash
sz login
sz login --no-browser
sz login --help
```
## Output and side effects
A JSON object with `loggedIn: true` and `identity` after validation and persistence. The identity includes a representative visible `workspace`, credential ID and permission metadata, never the API-key secret. Progress, URL and confirmation code go to stderr. Denial, expiry or failed validation returns a nonzero exit code. Browser-created keys expire after 90 days.
## Authorization
Normal Scheduler Zero browser authentication and explicit human consent are required to issue a key. Granted access is restricted and intersected with the owner's live authority. API-key validation uses the credential itself; it does not widen its grants. To change access when a key is already available, clear the saved key and unset the environment key before requesting fresh consent.
## Underlying operations
- `me.whoami`
- `personalApiKeys.issuance`
- `personalApiKeys.create`
Browser issuance stays a human-approved handoff where applicable; the command does not bypass that boundary. The exact product operation schemas are in [OpenAPI](/openapi.json) and [the REST Markdown reference](/rest-api/reference.md). For broader capabilities, use [MCP tools](/mcp/tools).
## Related documentation
[Browser consent and key lifecycle](/cli/authentication) · [SSH/manual login](/cli/authentication) · [Configuration](/cli/reference)
[All CLI commands](/cli/commands) · [Troubleshooting](/cli/troubleshooting) · [This command as Markdown](/cli/commands/login.md) · [CLI LLM index](/cli/llms.txt)