lpm security

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

LPM CLI keeps the security floor that you approve. This floor is the minimum protection that LPM CLI accepts. A command, repository, or AI agent cannot lower it without your approval.

For example, an AI agent can try to bypass your 24-hour release-age rule with --allow-new. A repository can also request weaker release-age, script, or sandbox settings. LPM CLI blocks the weaker setting until you approve an exception. Approval uses the security method for your operating system, such as Touch ID, Windows Hello, or a system password.

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

The command does not run an install or change a package. It manages the security state that guarded commands use.

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.

For clarity, use --project . or --global in scripts and saved instructions.

Recipes

Inspect a project

Run this command from the project root:

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.

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. On Unix, LPM CLI uses sudo for a restricted internal helper. The helper can change only the fixed managed-policy path and accepts only the supported protection actions.

Repair invalid local security state

If LPM CLI reports an invalid signature, 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 <DURATION>] [--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.

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.

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 device-owner approval.

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 fail instead of opening an approval 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
    },
    "active_runtime_overrides": [],
    "active_unlocks": []
  }
}

The full response also includes floor_sources, approved_posture_path, approved_posture_source, and an optional managed_policy object.

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. In an interactive terminal, it requests approval before it saves a weaker security value.

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

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 in the same file.

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 or edit.

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 the audit log. It renames each invalid file with an .unverified-... suffix.

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