lpm security

Use lpm security to inspect or manage security approvals on your computer.

lpm security <COMMAND> [--json]

lpm security status [--project <PATH> | --global]
lpm security unlock <SCOPE> [--project <PATH> | --global] [--ttl <TTL>] [--package <PKG>...]
lpm security lock <SCOPE> [--project <PATH> | --global] [--package <PKG>...]
lpm security protect status
lpm security protect enable [--firewall <FIREWALL>]
lpm security protect disable
lpm security repair

A security floor is the minimum protection that guarded LPM CLI commands accept. Weaker command flags or project settings require approval.

The command manages that approval state. It does not install or change a package.

Quickstart

Inspect the security state for the current project:

lpm security status

The output shows the effective security floor, its sources, runtime overrides, and active project unlocks.

Choose a command

unlock and lock default to the global target. status defaults to the current project.

Use --project . for an ordinary project. Global grants apply to global-install operations and machine floor edits. They do not unlock every project.

Use an explicit target in scripts and saved instructions.

Project and user configuration

lpm security does not read settings from lpm.json.

Security-sensitive settings can come from package.json, lpm.toml, environment variables, or ~/.lpm/config.toml. These values are requests, not approval by themselves.

Examples of guarded project settings include:

• package.json > lpm.scriptPolicy = "allow"
• package.json > lpm.minimumReleaseAge = 0
• package.json > lpm.minimumReleaseAgePolicy = "direct"
• lpm.toml > [sandbox] mode = "none"
• Wider trustedDependencies, trustedScopes, passEnv, readProject, or sandboxLimits values

If a setting weakens the approved floor, LPM CLI rejects it until you approve the required scope.

Use lpm config for persistent user settings. A weaker value requires fresh approval or an active global floor-edit grant.

Local approval state follows LPM_HOME. Each LPM home keeps its own approval files and OS credential store entries, so approvals made with one home don't apply with another. Use an OS-managed policy when protection must also apply with a different LPM home.

A managed policy has higher authority than user or project settings. You cannot unlock a change that the managed policy prohibits.

Recipes

Inspect a project

Run this command in the project or one of its subdirectories. Without --project, it reports the nearest directory with a package.json and prints that directory when it is not the current one:

lpm security status

Use --project to inspect another project:

lpm security status --project /path/to/project

Use --global to inspect global unlocks:

lpm security status --global

Approve one temporary project exception

Suppose an install reports that sandbox-none requires approval. Create a ten-minute project unlock:

lpm security unlock sandbox-none --project . --ttl 10m
lpm install --no-sandbox

The unlock command requests approval in an interactive terminal. It does not run the install.

If the original error includes suggested_command, copy that command. It contains the required scope and target.

Limit an exception to one package

If the reported exception applies to a specific package, use --package:

lpm security unlock provenance-ignore-drift \
  --project . \
  --package esbuild \
  --ttl 10m

Repeat --package to include more packages. Package filters work only with one concrete scope.

Revoke an exception early

Use the same scope, target, and package filters that you used for the unlock:

lpm security lock provenance-ignore-drift \
  --project . \
  --package esbuild

The command removes matching temporary unlocks. It does not change project files or the approved machine floor.

Approve a short configuration session

Approve machine floor edits for five minutes, then apply an explicit configuration change:

lpm security unlock floor-edit --global --ttl 5m
lpm config scripts --set triage --json
lpm security lock floor-edit --global

Only the unlock step requires interactive device approval. A valid global grant permits the configuration command to run without another prompt.

The grant expires, but the approved configuration changes remain. The grant cannot override managed policy. While force-security-floor is active, lower controls remain protected. The grant permits an explicit change to that switch through lpm config.

Protect npm installs on this computer

Enable managed LPM Firewall enforcement:

lpm security protect enable
lpm security protect status

Use monitor mode to report verdicts without blocking packages:

lpm security protect enable --firewall monitor

The enable and disable commands change an OS-managed policy file. Run each command as your normal user and approve operating-system elevation.

On Unix, LPM CLI uses sudo. On Windows, it uses an administrator prompt. The privileged operation changes only the fixed policy file.

Repair invalid local security state

If LPM CLI reports an invalid signature or an inconsistent audit history, use repair:

lpm security repair
lpm security status

The command moves invalid files to quarantine. It does not silently trust or delete them.

Temporary unlocks

lpm security unlock <SCOPE> [--project <PATH> | --global] [--ttl <TTL>] [--package <PKG>...]

An unlock approves a guarded exception for a limited time. The default lifetime is 10m, and the maximum is 365d.

Durations can use seconds, minutes, hours, or days:

lpm security unlock cooldown-bypass --project . --ttl 600
lpm security unlock cooldown-bypass --project . --ttl 30m
lpm security unlock cooldown-bypass --project . --ttl 2h
lpm security unlock cooldown-bypass --project . --ttl 7d

The value must be at least one second. Supported suffixes are m, h, and d.

If you omit both target flags, the command creates a global unlock. A project unlock applies only to its project root.

A global install uses global grants. An ordinary project uses its own project grants.

Scope selectors

Use the concrete scope from the approval error. The available scopes are:

You can also use a bundle selector:

• default includes the 12 common install and runtime scopes.
• all includes all 16 concrete scopes.

default excludes trust-bulk-approve, trust-scope-widen, capability-widen, and floor-edit.

Do not use all unless you need every exception. Neither bundle accepts --package.

Revoke temporary unlocks

lpm security lock <SCOPE> [--project <PATH> | --global] [--package <PKG>...]

lock is non-interactive. It revokes matching scopes from active unlocks.

If an unlock contains several scopes, LPM CLI removes only the selected scopes. The other scopes remain active. Concurrent lock commands preserve each other’s revocations.

Without --package, the command matches any package filter. With --package, it matches the exact normalized package set.

If no unlock matches, the command reports that it made no change.

Interactive approval and automation

lpm security unlock requires an interactive terminal and operating-system approval:

If Windows Hello or PIN is unavailable or unconfigured, the command fails. Configure a supported method before you retry.

It refuses to create an unlock in these cases:

• You use --json.
• Standard input or output is not a terminal.
• CI is set to 1, true, or yes.

The error uses security_approval_required and includes a suggested_command.

Do not create permanent unlocks for CI. Keep the security floor enabled, or configure an approved managed policy for the machine.

Direct command-line exceptions can request approval during an interactive command. Examples include:

lpm install --no-sandbox
lpm install --allow-new
lpm install --yolo
LPM_PROVENANCE_ENFORCE=off lpm install

In CI, JSON mode, or a non-interactive shell, these commands need an existing matching grant. Otherwise, they fail without opening a prompt.

Status output

lpm security status [--project <PATH> | --global]

Terminal output shows:

• The selected project or global target
• The script, release-age, sandbox, Sigstore, typosquat, LPM Firewall, and install-time source analysis floors
• The source of each displayed floor value
• The approved-posture path and active managed policy
• Active runtime overrides
• Active unlocks, package filters, and expiry times

Use JSON to get the same status in a structured object:

lpm security status --json

The command returns a stable top-level envelope:

{
  "success": true,
  "status": {
    "target": "project",
    "project_root": "/path/to/project",
    "effective_floor": {
      "script_policy": "deny",
      "minimum_release_age_secs": 0,
      "release_age_policy": "direct",
      "sandbox_mode": "default",
      "sandbox_allow_degraded": false,
      "sigstore_verify": "deny",
      "typosquat_guard": "default",
      "firewall_mode": "off",
      "install_time_source_analysis": false
    }
  }
}

The full response also includes floor_sources, approved_posture_path, approved_posture_source, and an optional managed_policy object. Empty active_runtime_overrides and active_unlocks arrays are omitted.

Managed machine policy

lpm security protect manages the LPM Firewall entry in the OS-managed policy file:

Unix/macOS: /etc/lpm/security-policy.toml
Windows:    C:\ProgramData\lpm\security-policy.toml

protect enable uses enforce by default. It also accepts --firewall monitor. It does not accept off.

protect disable removes only the managed firewall entry. It preserves other controls, including install-time-source-analysis, in the same file.

protect status reports active protection for monitor and enforce. An administrator-written off value reports inactive protection.

Administrators can manage a complete policy directly:

script-policy = "deny"
minimum-release-age-secs = 86400
release-age-policy = "strict"
typosquat-guard = "on"
install-time-source-analysis = true

[policy]
name = "corp-default"
source = "mdm"

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

[sigstore]
verify = "deny"

[firewall]
mode = "enforce"

The policy path and its parent directories must be controlled by the operating-system administrator. LPM CLI rejects a policy that other users can replace, edit, or delete.

Use TOML tables for [sandbox], [sigstore], and [firewall]. A scalar or array in place of these sections is a configuration error.

Recovery

If a signed security file has an invalid signature, run repair. Also run it if the signing secret is missing:

lpm security repair

The command verifies the approved posture, approval state, unlocks, and audit history. It renames unverifiable files with an .unverified-... suffix.

If the audit log differs from its signed record, repair quarantines both existing files. New audited actions then start a fresh history.

If the operating-system credential store returns an unexpected error, repair stops. It does not quarantine files that it cannot verify.

After a repair, run:

lpm security status

LPM CLI uses its built-in security floor and any valid managed policy until you approve new local state.

Use JSON to record the repair result:

lpm security repair --json

{
  "success": true,
  "repair": {
    "security_dir": "/Users/alice/.lpm/security",
    "quarantined": [
      {
        "original_path": "/Users/alice/.lpm/security/approved-posture.json",
        "quarantine_path": "/Users/alice/.lpm/security/approved-posture.json.unverified-20260531T121314.000Z",
        "reason": "signature verification failed"
      }
    ]
  }
}

JSON output

Use --json with read-only commands and non-interactive changes:

lpm security status --json
lpm security lock sandbox-none --project . --json
lpm security protect status --json
lpm security repair --json

unlock --json always refuses because creating an unlock requires interactive approval.

Successful lock, status, protect, and repair responses use success: true. The response contains the affected scopes or result details.

Flags

For each command, --project and --global are mutually exclusive. Bundle scopes do not accept --package.

See the other global flags.

See also

• lpm install - run installs with guarded security options
• lpm config - manage persistent user security settings
• ~/.lpm/config.toml - review user configuration and precedence
• lpm.toml - configure project sandbox behavior
• Exit codes - handle approval and security-floor failures