~/.lpm/config.toml

~/.lpm/config.toml stores user defaults for LPM CLI across projects. Each setting has its own precedence rules. Security controls also depend on approved machine settings and managed policy.

lpm config set save-prefix '~'
lpm config get save-prefix
lpm config list --json
lpm config unset save-prefix

Use lpm config for supported changes. Edit the file directly for arrays and policy extensions. Use lpm.toml or package.json > lpm for supported project defaults.

File location

LPM_HOME moves the configuration file with the rest of the LPM home: login state, local env secrets, the store, caches, and the global installation root. The file is created on the first configuration write. A missing file supplies no user overrides. Configuration reads have a 16 MiB limit. Security-sensitive commands reject read errors, malformed TOML, and invalid security controls before applying them. Individual settings have additional validation rules described below.

Known keys

Start with the settings that your machine needs:

save-prefix = "~"
workspace-concurrency = 4

[sandbox]
mode = "default"
allow-degraded = false

Save policy and workspace commands

Project lpm.toml overrides each save key independently. Explicit save flags take precedence. Explicit dependency specifications and existing entries have separate preservation rules. See Save policy.

Workspace concurrency resolves from the CLI flag, workspace-root lpm.toml, this file, then host parallelism. If host parallelism is unavailable, the fallback is four.

lpm config set workspace-concurrency 4
lpm run build --all --workspace-concurrency 2

Installation

engine-strict uses the workspace-root project value before this file. --no-engine-strict overrides both. Peer settings use the project value before this file. Explicit strict-peer flags override both sources.

Automatic package skills resolve from --skills or --no-skills, the canonical user key, inverted noSkills, then true. The configuration command removes the legacy key when it writes the canonical setting. Disabling automatic skills does not delete existing skills or affect explicit lpm skills add.

Source analysis and Registry insights are independent. Re-enabling source analysis fills missing or outdated analysis caches from existing package bytes. lpm audit can still analyze packages while install-time analysis is disabled.

Audit-after-install resolves from its CLI flags, a valid LPM_AUDIT_AFTER_INSTALL value, this file, then false. An invalid environment value falls back to this file. noSecuritySummary combines with its CLI flag: either true value hides the summary.

Lifecycle scripts and sandbox

Script policy and advisor selection resolve from CLI flags, project values, this file, then defaults. The advisor runs only for triage. Execution approvals last for one install. Verdict caching is separate.

autoBuild combines with the CLI and project values: any true value requests the rebuild. An allow policy or a fully trusted pending set can also trigger a rebuild. denyAll still prevents execution.

Sandbox mode resolves from CLI flags, true LPM_STRICT_SANDBOX, project lpm.toml, this file, then its default. Sandbox degradation uses the project value before this file. All reductions remain subject to security approval.

Read allowances combine with project sandboxReadAllow entries. Directories, symlinks, and paths outside the project are rejected. Write roots can use ~/. Relative roots are ignored. Protected system and credential paths remain denied. See script capabilities.

Release cooldown

Minimum age resolves from the CLI flag, project value, this file, then zero. The age policy resolves from the project value, this file, then direct. The string "default" also means direct. Exclusions merge CLI entries, project entries, and user entries, with duplicates removed. allowNew combines with --allow-new.

lpm config set minimum-release-age-secs 86400
lpm config release-age-exclude add @acme/internal
lpm install --min-release-age 2d

Exclusions reject version ranges and protocol dependencies. See the supported forms in lpm config. Approved floors can prevent a lower age or broader exclusion.

Integrity and package verification

signatures = true
trust-policy = "no-downgrade"
integrity = "tree"
typosquat-guard = "on"

[sigstore]
verify = "deny"
scope = "all"
availability = "strict"

LPM_VERIFY_REGISTRY_SIGNATURES overrides signatures. LPM_V2_OBJECT_INTEGRITY overrides integrity. LPM_PROVENANCE_ENFORCE overrides provenance posture, subject to approved floors. See Environment variables for accepted values.

trust-policy uses this file. Unknown strings and non-string values fail instead of disabling the policy. The verified artifact-history floor applies even with provenance warnings, skip flags, or best-effort availability. Attestation pointers alone do not establish verified history.

A valid explicit typosquat setting takes precedence over the diagnostic environment toggle. default removes the explicit setting through the CLI. It cannot weaken an approved or managed guard without approval. Use project typosquat exceptions for intentional package names.

npm firewall policy profile

LPM Firewall checks npm package verdicts. Its hosted service requires an LPM.dev Registry Pro or Org account. Use lpm login locally or LPM_TOKEN in CI.

[firewall]
mode = "monitor"

[firewall.npm.policies]
trusted_public_malicious_advisories = "block"
lpm_ai_confirmed_malware = "block"
lpm_ai_agent_control_surface = "warn"
critical_vulnerability = "warn"
lpm_ai_suspicious = "warn"

firewall.mode accepts off, monitor, and enforce. The default is off. Monitor mode warns and continues. Enforce mode blocks denied packages. The listed actions are the default profile. Each group accepts allow, warn, or block. Unknown policy names and invalid actions fail validation.

LPM_NPM_FIREWALL can tighten the user mode but cannot weaken it. report is a compatibility alias for monitor. The legacy static_only_suspicious group applies only when lpm_ai_suspicious is absent. Configuration commands write canonical names.

Installs read profiles when LPM Firewall is active. lpm config list also checks inactive profiles. See Firewall for npm for policy meanings, mode aliases, and entitlement behavior.

Policy extensions

Local extensions supply package verdicts before registry downloads and linking. Lockfile and offline replay still run these checks.

[policy.extensions.local-feed]
command = ["/usr/local/bin/lpm-policy-feed", "--deny-list", "/etc/lpm/deny.json"]
mode = "enforce"
on-error = "block"
timeout-ms = 5000
events = ["package.candidate"]

Extensions run in name order. The executable must be an absolute path or a program from an absolute PATH directory. LPM CLI starts it directly with a restricted environment and exchanges JSON through stdin and stdout. Relative executables and empty arguments are rejected.

Unknown extension fields fail even when enabled = false. Disabled extensions can omit command and skip the other known-field checks. warn aliases report mode. deny and block alias enforce mode. For on-error, report aliases warn, while deny and enforce alias block.

Extensions use this user file. They are separate from signed machine approvals and managed policy. Active extensions reject direct remote tarball dependencies before download. See lpm policy for the request and response formats, output bounds, and troubleshooting.

lpm policy list --json
lpm policy test local-feed --package react@19.0.0 --json

Tunnel relay

[tunnel]
relay-url = "wss://relay.lpm.fyi/connect"

A nonblank LPM_TUNNEL_RELAY value overrides the saved URL. The endpoint must use wss://, or ws:// on loopback. An invalid selected endpoint produces a warning and uses the default shown above. An invalid environment endpoint does not retry the saved URL. See lpm tunnel for relay trust and connection recovery.

String coercion

Native TOML types are recommended. Generic configuration writes can store strings. Readers accept specific aliases according to the setting:

These strings are exact and case-sensitive unless the setting documents another parser. Automatic skill installation also accepts whitespace and case variations. typosquat-guard accepts string aliases with whitespace and case variations, but not native TOML Booleans.

Unknown top-level keys usually have no effect. Firewall policy names and extension fields are exceptions. Invalid-value behavior also differs:

• Invalid force-security-floor or trust-policy values fail security-sensitive reads and configuration writes.
• Invalid sigstore.verify values fall back to deny.
• Unknown string values for linker, sigstore.scope, and sigstore.availability fail. Non-string values act as absent during installation.
• Invalid ordinary Boolean values usually act as absent. Source analysis, Registry insights, and automatic skill settings have stricter readers.
• Invalid user script policy acts as absent. Unknown advisor strings warn and select no advisor.

lpm config list checks more fields than an individual command and can reject values that command-specific readers ignore.

Security-sensitive keys are proposals

A hand edit cannot independently authorize weaker protection. LPM CLI also checks signed machine approvals, temporary unlocks, and managed policy. An unauthorized reduction fails with security_approval_required. Managed policy can reject it with security_floor.

Use lpm security for temporary exceptions. Use lpm config for persistent approved changes. JSON and non-interactive commands do not display approval prompts.

To remove an active force-security-floor, first obtain a global floor-edit grant:

lpm security unlock floor-edit --global
lpm config unset force-security-floor

An active grant also permits lpm config set force-security-floor false. Project grants, expired grants, and default unlock scopes do not authorize this persistent change. The change does not remove other approved controls or managed policy. Invalid hand-edited values must be corrected before security-sensitive commands can continue.

Precedence

There is no universal order across all configuration files. Use the rules in each setting group. CLI flags can replace values, combine with them, or add list entries.

Global installations use user defaults and supported CLI or environment overrides. They do not inherit settings from the caller's project manifest. For example, trust-policy remains a user setting, while integrity also has an environment override. See lpm global for supported global flags.

Exception — linker

The layout selection order is:

1. lpm install --linker.
2. User linker in this file.
3. Nonempty LPM_LINKER.
4. Project package.json > lpm > linker.
5. Automatic selection.

Automatic selection uses hoisted layout for single packages and isolated layout for workspaces. A default install with peer conflicts also switches to isolated layout. An explicit value disables that automatic switch. Changing the selected layout invalidates the install state and relinks on the next install. See dependency layout and lpm install.

See also

• lpm config
• lpm security
• lpm policy
• lpm.toml
• package.json > lpm
• Environment variables