Authentication
The CLI uses email-based authentication against the public control-plane API. A successful login stores a session token in a local JSON file; subsequent commands read that token automatically. Logging out removes the file.
Both Space admins and Space members use the same login flow:
- Admins log in with an admin auth key, then create and manage Spaces
- Members log in with a member auth key they received from a Space admin, then list Spaces and connect to their Space session
Test harness -- in normal use, just run "spaces" directly.
. .specdown/test-env
tmp=$(mktemp -d)
spaces_issue_auth_key alice@example.com admin > "$tmp/auth.key"
chmod 600 "$tmp/auth.key"
cat > "$tmp/spaces" <<WRAPPER
#!/bin/sh
export SPACES_BASE_URL=$SPACES_BASE_URL
: "\${SPACES_SESSION_FILE:=$tmp/session.json}"
export SPACES_SESSION_FILE
exec $SPACES "\$@"
WRAPPER
chmod +x "$tmp/spaces"
printf '%s\n' "$tmp/spaces" "$tmp"rm -rf ${tmp}Login
Authenticate with your email and a one-time auth key provided by your
platform approval flow or by your Space admin. On a terminal,
spaces login alice@example.com
prompts for the auth key automatically and masks what you type with *.
For non-interactive shells, use --key-file or --key-stdin. The
executable example here stays non-interactive by using --key-file:
... (1 line)
Who Am I
Check which account is currently logged in:
Logout
End the current session and remove the local session file:
... (1 line)
After logout, commands that require authentication return an error: