lpm config

lpm config <action> [key] [value]

Manages ~/.lpm/config.toml — the per-user CLI defaults file. For ordinary keys it is a convenience layer over editing the file by hand. For security-sensitive keys, it is also the approved path for persisting a weaker machine posture.

Examples

lpm config list                                 # show every set key
lpm config get save-prefix                      # → "^"
lpm config set save-prefix '~'                  # write
lpm config set script-policy triage             # write
lpm config release-age --set 1d                # human-friendly release cooldown
lpm config set minimum-release-age-secs 3600    # 1h cooldown
lpm config set workspace-concurrency 4          # workspace run/test/bench fan-out
lpm config set audit-after-install true         # enable audit-after-install globally
lpm config delete save-prefix                   # remove
lpm config unset save-prefix                    # alias for delete

Actions

Action	Aliases	What it does
`get <key>`	—	Print the value of a single key (empty if unset)
`set <key> <value>`	—	Write the value into `~/.lpm/config.toml`
`delete <key>`	`unset`	Remove the key from the file
`list`	`ls`	Print every key/value pair currently stored

set always writes the value as a TOML string. The reader accepts both string and native types, so this is safe — see String coercion for the rationale.

Known keys

The reader accepts unknown keys silently (forward compatibility), but only the following keys actually do anything today:

Key	See
`save-prefix`	Save policy
`save-exact`	Save policy
`script-policy`	Lifecycle scripts
`triage-advisor`	Optional LLM advisor
`minimum-release-age-secs`	Recently published packages — raw key; the recommended setup surface is `lpm config release-age`
`workspace-concurrency`	Task runner — workspace package fan-out cap for `lpm run`, `lpm test`, and `lpm bench`
`audit-after-install`	Audit after install
`[sandbox] mode`	Sandbox — only writable via `lpm config sandbox` (nested key)
`[sigstore] verify`	Provenance — recommended setup surface is `lpm config sigstore`

The full reference for these keys, their types, defaults, and precedence chain is on ~/.lpm/config.toml.

Setup wizards

Five of the keys above have dedicated interactive wizards that handle picking + validation for you:

lpm config scripts                          # pick deny / triage / allow
lpm config scripts --set triage             # non-interactive

lpm config triage                           # pick none / claude-cli / codex / ollama
lpm config triage --set claude-cli          # non-interactive

lpm config sandbox                          # pick default / strict / none
lpm config sandbox --set strict             # non-interactive

lpm config sigstore                         # pick deny / warn / off
lpm config sigstore --set deny              # non-interactive

lpm config release-age                      # pick default / 3d / off / custom
lpm config release-age --set 3d             # non-interactive

lpm config triage auto-detects which advisor providers are installed on your machine and only offers the available ones (plus none). Picking none in lpm config sandbox adds an extra approval step, and picking off in lpm config sigstore does the same. The --set forms still persist through the same guarded flow: in an interactive TTY they ask for native system approval, and in --json / CI / non-TTY mode they fail with security_approval_required instead of silently weakening the machine floor.

lpm config release-age accepts default, off, or human durations like 12h, 1d, 3d, and 0. The wizard persists canonical seconds into minimum-release-age-secs, but the interactive and --set surfaces stay duration-based. Picking default removes the global override and falls back to the built-in 24h default.

All five wizards write to the same ~/.lpm/config.toml that lpm config set would. They require a TTY when invoked without --set; non-interactive callers must always pass --set <value>.

Security-sensitive writes

Lowering machine-wide security posture through lpm config is guarded.

Examples:

lpm config scripts --set allow
lpm config release-age --set 0
lpm config sandbox --set none
lpm config sigstore --set off

In an interactive TTY, LPM asks for confirmation before persisting the weaker value.

In --json, CI, or any non-TTY shell, the same write fails with error_code: "security_approval_required" instead of silently lowering the machine floor.

If a managed policy owns that control (/etc/lpm/security-policy.toml on Unix/macOS, C:\ProgramData\lpm\security-policy.toml on Windows), the write fails with error_code: "security_floor" instead.

Directly editing ~/.lpm/config.toml is not equivalent to approval for these keys. A raw file edit is only a proposal; when the value is weaker than the current approved floor, LPM refuses with security_approval_required or security_floor. In particular, raw [sigstore].verify = "warn" or "off" is surfaced as an active runtime override and requires a provenance-unverified unlock before mutating install or trust flows proceed.

File location

~/.lpm/config.toml (or %USERPROFILE%\.lpm\config.toml on Windows). Override the entire ~/.lpm/ root with LPM_HOME.

The file is created on demand the first time you set a key.

Flags

lpm config takes no specific flags besides the global flags and the wizard-only --set <value>. --json returns structured output for every action — get / set / delete / list and the five wizards all emit a {success, …} envelope under --json.