lpm setup

Generate scoped authentication for npm-compatible clients in CI. For LPM CLI itself, LPM_TOKEN is the direct non-interactive authentication surface.

lpm setup ci npmrc

Examples

lpm setup ci npmrc                       # generate .npmrc with resolved literal auth
lpm setup ci npmrc -r https://lpm.dev    # override registry URL
lpm setup local                          # 30-day read-only project token
lpm setup local --days 90                # maximum validity

lpm setup ci npmrc

Generates an .npmrc in the current project directory for CI/CD environments. Other npm-compatible clients can then install @lpm.dev/* packages from CI. On Unix, the file is set to 0o600 because it can embed auth material.

By default, the generated file uses scoped routing:

# LPM Registry (generated by lpm setup ci npmrc)
//lpm.dev/:_authToken=<resolved-literal-token>
@lpm.dev:registry=https://lpm.dev/api/registry/
# End LPM Registry

Generated setup files are always scoped to @lpm.dev. Public npm packages keep using the normal npm route or whatever default registry your existing .npmrc declares.

The command resolves an actual bearer from an explicit --oidc exchange, LPM_TOKEN, or an eligible stored login. If none is available, it exits before changing .npmrc and tells you to set LPM_TOKEN or run lpm login. An explicit OIDC exchange failure never falls back to another credential.

The command preserves unrelated .npmrc entries, atomically replaces only its generated block, and writes the file with owner-only permissions on Unix. If it displaces a token created by lpm setup local, that token authenticates its own self-revocation before .npmrc changes. Repository-controlled token IDs or hashes never select the revocation target, and the replacement credential can come from OIDC, LPM_TOKEN, or another non-session read token. An already-inactive predecessor is safe to replace; a timeout, server error, or denied self-revocation leaves the old protected block unchanged for retry. The command also refuses to retire and rewrite the same bearer.

Finish a pending lpm setup local replacement before switching to CI setup. Recovery markers written by older clients contain only an ID or hash and cannot prove possession, so LPM CLI fails closed and directs you to revoke those tokens in the dashboard before removing the generated block. Under --json, the on-disk file is still written, but the returned content field shows <redacted> and never includes the bearer.

LPM CLI can consume LPM_TOKEN directly. The generated project file exists for npm-compatible clients that need a literal bearer; LPM CLI continues to reject sensitive environment expansion from repository-controlled .npmrc files.

Local authentication

lpm setup local uses your verified, refresh-backed CLI login to mint a project-specific read-only token:

lpm login
lpm setup local             # 30 days
lpm setup local --days 90   # allowed range: 1–90

It atomically preserves unrelated .npmrc settings, replaces its own generated block idempotently, routes only @lpm.dev/* to LPM.dev Registry, writes the token-bearing file with owner-only permissions on Unix, and leaves custom default registries unchanged. It also ensures .npmrc appears exactly once in .gitignore.

# LPM Registry (generated by lpm setup local — do not commit)
# LPM project token id: <non-secret-token-id>
@lpm.dev:registry=https://lpm.dev/api/registry/
//lpm.dev/api/registry/:_authToken=<read-only-project-token>
# End LPM Registry

The server returns the actual scope and expiry, and JSON output reports them without exposing the one-time token. Project tokens are independent of the CLI session that created them, so revoking that session does not unexpectedly invalidate unrelated project installations.

Re-running the command replaces the previous generated setup token instead of accumulating active tokens. LPM CLI commits the .gitignore protection and a recoverable pending .npmrc block before contacting the Registry. The Registry then creates the client-generated replacement and revokes the predecessor in one transaction. A retry sends the same token ID and secret, so a lost response cannot create another token or cause the CLI to restore a predecessor that the server already revoked. During an ambiguous retry, the owner-only, gitignored pending block retains the predecessor bearer alongside the new pending bearer so the CLI can derive the same replacement request without trusting repository-controlled IDs or hashes. After the Registry confirms the transaction, LPM CLI removes the predecessor and changes the pending marker to the stable non-secret token ID shown above.

If the request times out, the Registry returns an ambiguous server failure, or the success body cannot be validated, the protected pending block remains usable and .npmrc remains ignored. Rerun lpm setup local with the same Registry to resolve the transaction idempotently. A deterministic client error restores the previous generated block because the Registry rejected the mutation. Pending blocks written by older clients with only predecessor ID/hash markers require dashboard cleanup because those markers cannot authenticate the predecessor.

See also

• Authentication - how tokens are stored
• lpm login / logout / whoami - manage local registry sessions
• lpm env - environment variables, secret sync, and CI OIDC policies
• CI/CD setup - full workflow setup
• .npmrc format