Account authorization

Authorize the CLI to act on your Loom account with a limited set of capabilities:

loom auth account --url https://loom.example --flow browser
loom auth account --url https://loom.example --flow device

Use --flow browser when the browser opens on the same machine as the CLI. The CLI reserves a temporary loopback port before opening the browser. If the browser cannot open, use its displayed authorization URL on that machine or rerun with --flow device. A browser on another machine cannot return to this CLI's loopback listener; use device flow for a remote or headless shell. Device flow displays a verification URL and user code, then polls until approval, denial or expiry. It does not open an inbound listener.

The default requested capabilities are projects:read, projects:create, and project-credentials:issue. Request a smaller set by repeating --scope:

loom auth account --url https://loom.example --flow device --scope projects:read

Approval shows the effective scopes. Web requires a fresh consent decision for each authorization, even with an existing approval. An unknown scope fails before authorization begins. Normal workflow runs do not open a login prompt. An existing browser session may approve without another password entry; the CLI never reads browser cookies or stores a browser session token.

View only the selected account's local metadata or revoke this device login:

loom auth account status --url https://loom.example --account ACCOUNT_ID
loom auth account logout --url https://loom.example --account ACCOUNT_ID

Status shows origin, account ID, login ID, effective scopes, access expiry and file-storage state. It never prints access or refresh credentials. Logout requests remote revocation of this login and its derived project credentials, then removes its local material. If the server cannot confirm revocation, the CLI says that server access may remain active even though the local credential was removed. Other device logins and independent CI credentials are separate.

Credentials are kept as unencrypted JSON at exactly ~/.config/loom/auth.json on Linux and macOS, with a private ~/.config/loom directory and file permissions. There is no keychain or XDG path fallback. The CLI distinguishes an absent store from an expired, rejected, unavailable, corrupt or unsafe one. A lost one-time exchange response or ambiguous refresh requires an explicit new loom auth account login; the CLI will not retry a possibly consumed refresh credential. If replacement or local saving fails after server issuance, authorization may have succeeded remotely: check server access and start a fresh explicit login. No token, pasted environment variable or workflow secret entry is part of ordinary setup.

Private file permissions protect against other OS users. A process running as your same user, including a host-executed workflow job, can read your home files; the credential store does not isolate it. Use only trusted host workflows while logged in.