Authentication

LPM CLI stores auth material in your local secure store and keeps each registry separate. A normal lpm login session authenticates you to the LPM.dev Registry, while npm, GitHub Packages, GitLab Packages, and custom npm-compatible registries can each have their own token source.

GitHub and GitLab can use the host CLIs directly. When gh or glab already has a valid session, LPM CLI can read that token at command time without copying it into LPM CLI storage. Explicit token fallbacks, npm web-login tokens, custom registry tokens, and LPM.dev Registry sessions are stored by LPM CLI.

Registry model

This storage split is why lpm logout without flags clears only the LPM.dev Registry session. Use lpm logout --all when you want to clear every stored registry token.

NPM_TOKEN and tokens stored by lpm login --npm are scoped to https://registry.npmjs.org. A repo can route publishing or staging to a custom npm-compatible registry in lpm.json, but that route does not redirect npmjs.org credentials. Use lpm login --login-registry <URL> --token <T> for each custom publish registry.

Token storage

Service name: lpm-cli. Account names are scoped per registry: the LPM.dev Registry, npm, GitHub, GitLab, and custom registries each get their own keychain entry.

If the system keychain is unavailable, such as in a sandboxed environment, headless Linux session without D-Bus, or locked store, the CLI falls back to encrypted file storage at ~/.lpm/.credentials. Tokens still do not land in plaintext on disk.

On macOS, LPM CLI first probes a stored access or refresh credential with Keychain interaction disabled. A credential that is already authorized is returned silently. If macOS reports that user interaction is required, LPM CLI prints the matching Keychain guidance and immediately retries with UI allowed; this is the point where the permission sheet can appear. Missing credentials, unrelated Keychain failures, and encrypted-file fallback reads do not print the guidance. After you choose Always Allow, later authorized reads remain silent.

You can see the active backend in:

lpm login
lpm whoami
lpm whoami --json
lpm setup ci npmrc --json
lpm doctor

setup ci npmrc requires LPM_TOKEN, an eligible stored session, or explicit OIDC. Its JSON output reports the source/backend and a redacted file shape; the live bearer appears only in the protected on-disk .npmrc.

The human wording is secure storage backend: keychain or secure storage backend: encrypted file fallback. The encrypted fallback is valid and encrypted, but lpm doctor treats it as degraded because it does not have the same OS-managed per-app protections as the keychain-backed path.

See also

• lpm login / logout / whoami - sign in, sign out, and inspect the active identity
• lpm setup - write .npmrc auth for CI or local development
• lpm token-rotate - rotate the LPM.dev Registry session token
• Registries - how LPM CLI routes between the LPM.dev Registry, npm, and private registries
• Environment variables - LPM_TOKEN, LPM_OIDC_TOKEN, and registry auth overrides