lpm config

Use lpm config to inspect active settings or save defaults for every project you use with LPM CLI.

lpm config [ACTION] [KEY] [VALUE] [--set <VALUE>] [--json]

lpm config
lpm config get <KEY>
lpm config set <KEY> <VALUE>
lpm config delete <KEY>
lpm config unset <KEY>
lpm config list
lpm config ls
lpm config <SETTING> [--set <VALUE>]
lpm config release-age-exclude [list]
lpm config release-age-exclude add <SELECTOR>
lpm config release-age-exclude remove <SELECTOR>

The command stores its changes in ~/.lpm/config.toml.

Quickstart

Open the guided editor:

lpm config

The editor shows the current values for its security and install settings. It returns to the main menu after each change.

To view the effective configuration for the current project and process, run:

lpm config list

Choose a command

get reads a saved value from ~/.lpm/config.toml. It does not calculate defaults or overrides. Use a dotted path for a nested field:

lpm config get sandbox.mode
lpm config get policy.extensions.local-feed.command

Explicit get returns the saved value, including secrets. The list and set output redact recognized secret values and credential arguments.

list resolves all known configuration keys. It includes built-in defaults, project configuration, user configuration, environment variables, and active security floors. It uses the current directory and process environment. It does not include flags from other commands.

Human output groups related keys and shows the effective value and source in separate columns. Named policy extensions add entries such as policy.extensions.<name>.mode. Unknown keys saved in ~/.lpm/config.toml remain visible in the Additional saved values group.

Project configuration

lpm config does not write lpm.json. It changes user defaults in ~/.lpm/config.toml.

Project configuration uses the file defined by each feature. For example, save policy uses lpm.toml, and linker configuration can use package.json > lpm.

Read the related feature page before you add a project override. Precedence is not the same for every key.

Focused settings

Omit --set to select a value in an interactive terminal. JSON mode and non-interactive shells require --set.

The lpm-dev editor manages lpm-skills and lpm-insights together. It does not accept --set or --json.

The interactive triage editor lists the advisor providers that it detects. Cloud advisors receive lifecycle script text, while Ollama keeps the text local.

If the triage editor offers to change script policy, it saves that change with the advisor choice. Cancellation leaves both saved values unchanged.

Common generic keys

Use lpm config set for scalar user defaults and the supported nested aliases.

See the complete key reference for arrays, nested tables, policy extensions, and all precedence rules.

The generic set action validates known scalar keys before it writes the file. It stores most values as TOML strings.

For save-exact, use true, false, 1, 0, yes, or no. Other Boolean keys also accept on, off, enabled, and disabled. Use lowercase values.

Unknown top-level keys remain available for custom configuration. Empty keys, dotted setters, and scalar writes to known array settings fail without changing the file.

The generic action also accepts these validated aliases for nested settings:

lpm config set sandbox strict
lpm config set sigstore scope=all
lpm config set firewall monitor

These aliases update one field in the related TOML table. They keep the other fields in that table. They use the same validation and security approval as the focused commands.

Use the focused sandbox, sigstore, and firewall commands in new scripts. The focused forms make the nested field clear.

The generic action rejects policy, tunnel, and every dotted key, including sandbox.mode. It does not change the file after this error. Edit ~/.lpm/config.toml directly when you must change an unsupported nested value.

The generic action also rejects minimum-release-age-exclude because this key requires an array. Use lpm config release-age-exclude add <selector> instead.

If another key requires an array or nested table, edit the file directly. For example, script-read-allow and max-sandbox-write-roots require TOML arrays.

Recipes

Change saved dependency ranges

Save new dependencies with a tilde range:

lpm config set save-prefix '~'

Save exact versions for all new dependencies:

lpm config set save-exact true

save-exact has priority over save-prefix. Project values in lpm.toml have priority over these user values.

Select a node_modules layout

Use the isolated layout for installs by this user:

lpm config set linker isolated

This user value has priority over LPM_LINKER and package.json > lpm > linker. The lpm install --linker flag has higher priority.

To let each project select its layout, remove the user value:

lpm config delete linker

Set workspace concurrency

Run four workspace members at the same time:

lpm config set workspace-concurrency 4

This value applies to workspace mode for lpm run, lpm test, and lpm bench.

Enable the audit summary after installs

Run a non-blocking audit after each successful install:

lpm config set audit-after-install true
lpm install

The audit prints one summary line. Its findings do not fail the install.

Set a stricter security baseline

If you want stricter package and script checks on your computer, use this recipe:

lpm config scripts --set deny
lpm config sandbox --set strict
lpm config sigstore --set scope=all
lpm config sigstore --set availability=strict
lpm config signatures --set true
lpm config trust-policy --set no-downgrade
lpm config integrity --set tree

Each command changes one independent control. You can apply only the controls that you need.

Typosquat guard

The guard is off by default. Enable suspicious-name checks for new direct dependencies:

lpm config typosquat --set on

--set default removes the explicit override and uses the disabled product default. --set off always disables the guard.

Install-time source analysis

Source analysis is off by default, including the local scan for the post-install summary. Enable source analysis during installation:

lpm config source-analysis --set true

The next install fills missing analysis caches from stored package bytes without another tarball download. It also scans installed files for the post-install summary. With this setting disabled, the summary skips local source analysis even with --verbose. Registry insights and firewall checks use separate settings. lpm audit can scan installed source independently.

Disabling an approved source-analysis setting or typosquat guard requires security approval. Managed policy can prevent either change.

Increase the release cooldown

Require a three-day cooldown for direct and transitive dependencies:

lpm config release-age --set 3d
lpm config release-age-policy --set strict

Use default to remove the user cooldown override. The built-in cooldown is off. Resetting an approved cooldown to this default requires security approval.

lpm config release-age --set default

Exclude selected packages from the release cooldown

Add a user exclusion that applies to all projects on this computer:

A new exclusion requires security approval, even when the cooldown is off. Run this recipe in an interactive terminal.

lpm config release-age-exclude add react
lpm config release-age-exclude add '@company/*'
lpm config release-age-exclude add react@19.1.0
lpm config release-age-exclude list

Remove an exclusion with the same complete selector:

lpm config release-age-exclude remove react@19.1.0

The command validates each selector and removes duplicate values. It atomically writes a string array to ~/.lpm/config.toml.

JSON output includes changed, normalized, count, and exclusions. Normalization can change the stored array without changing the requested selector.

It does not write to package.json or lpm.lock. Generic lpm config set minimum-release-age-exclude is rejected because it supplies a scalar value.

Use lpm trust release-age-exclude for a shared project exclusion.

See the lpm trust storage contract for the merge order and workspace behavior.

Monitor public npm packages with LPM Firewall

This recipe signs in, enables monitor mode, and runs an install:

lpm login
lpm config firewall --set monitor
lpm install

monitor prints verdicts and continues. enforce blocks a package when its effective policy action is block.

LPM Firewall is an LPM.dev Registry Pro or Org feature. See the LPM Firewall guide for policy-group controls.

Control LPM.dev Registry package features

Disable automatic package skills and registry behavior enrichment:

lpm config lpm-skills --set false
lpm config lpm-insights --set false

Disabling package skills keeps existing .lpm/skills/ files. Disabling insights does not disable local source analysis or explicit audits.

Security-sensitive changes

LPM CLI guards changes that weaken an approved security setting. Guarded controls include:

• Lifecycle script policy
• The release-age duration and scope
• The lifecycle-script sandbox
• Sigstore verification mode
• Typosquat analysis
• LPM Firewall mode
• Install-time source analysis

In an interactive terminal, LPM CLI requests approval before it saves a weaker value.

In JSON mode, CI, or a non-interactive shell, the command requires an active global floor-edit grant. Otherwise, it fails with security_approval_required.

See lpm security for a short, approved configuration session.

A managed policy or force-security-floor can prohibit changes to lower controls. In this case, the command fails with security_floor.

To disable or unset force-security-floor itself, obtain an active global floor-edit grant first. See user configuration.

Deleting a nested field follows the same checks as changing it. For example, deleting sandbox.mode cannot remove a forced strict sandbox setting.

Use lpm security status to inspect the active security floor and temporary approvals.

JSON output

Use --json with explicit actions or focused setters:

lpm config list --json
lpm config get save-prefix --json
lpm config integrity --set tree --json
lpm config set workspace-concurrency 4 --json

list --json returns one ordered entry for each effective key. The following shortened example shows the envelope and entry fields:

{
  "success": true,
  "action": "list",
  "count": 2,
  "entries": [
    {
      "key": "save-prefix",
      "value": "^",
      "source": "built-in default",
      "group": "Dependency saving"
    },
    {
      "key": "sandbox.mode",
      "value": "strict",
      "source": "lpm.toml",
      "group": "Lifecycle scripts"
    }
  ]
}

An active project scripts-allow or scripts-triage unlock can authorize a weaker project script policy. Its source includes temporary project unlock.

The real count is the number of objects in entries. Named policy extensions and unknown saved keys can increase this number.

For a saved key, get --json returns a stable envelope:

{
  "success": true,
  "action": "get",
  "key": "save-prefix",
  "value": "~",
  "found": true
}

If the key is not saved, the command returns the same envelope with a null value:

{
  "success": true,
  "action": "get",
  "key": "save-prefix",
  "value": null,
  "found": false
}

The command exits successfully for both states. Use found to determine if the configuration file contains the key.

The bare guided editor and lpm config lpm-dev do not support JSON mode.

Reset or recover the configuration

Remove a saved user value to use the next source in its precedence chain:

lpm config delete save-prefix
lpm config delete sandbox.mode

For a focused setting, use its focused command to select the documented default:

lpm config release-age --set default
lpm config typosquat --set default
lpm config sandbox --set default

If the file contains invalid TOML, keep a backup and start with built-in defaults:

mv ~/.lpm/config.toml ~/.lpm/config.toml.backup
lpm config

After LPM CLI opens the editor successfully, copy required values from the backup.

File location

The default path is ~/.lpm/config.toml. On Windows, the path is %USERPROFILE%\.lpm\config.toml.

The LPM_HOME environment variable changes the LPM home, the directory that holds this file. The LPM home also holds your login state, local env secrets, store, and caches, so another LPM_HOME starts without your saved login. LPM CLI creates the file when it saves the first value.

Arguments and flags

Other global flags also apply.

See also

• ~/.lpm/config.toml - read all keys, types, defaults, and precedence rules
• lpm security - inspect approvals and managed security floors
• lpm policy - inspect local install policy extensions
• lpm.toml - configure supported project-level behavior
• package.json > lpm - configure supported project-level package behavior
• Save policy - select dependency range formats