lpm dlx

Use lpm dlx for a package tool that you do not need as a project dependency. lpx runs the same command.

lpm dlx [OPTIONS] <PACKAGE> [ARGS]...
lpx [OPTIONS] <PACKAGE> [ARGS]...

Quickstart

lpm dlx cowsay@1.6.0 -- "hello"
lpx create-next-app@latest -- my-app
lpm dlx prettier -- --check src

The command installs the package in a cache, then runs its default executable from the current directory. It does not add a dependency to the project's package.json or node_modules. The package tool can create or change files in that directory.

Configuration

lpm.json has no dedicated dlx configuration. Ordinary dlx does not load project dotenv files, project secrets, or environment schemas. It does not prepare the runtime pins from lpm.json. Before each run, LPM CLI checks installed dependency engine requirements against Node on the tool's execution PATH. This PATH includes the caller's local binaries. For a tool that needs that project environment, install it and use lpm exec.

Package installation follows the caller's registry configuration and applicable security policy. For example, this package.json requires a release age of two days:

{
  "name": "my-project",
  "lpm": {
    "minimumReleaseAge": 172800
  }
}

lpm dlx create-next-app@latest -- my-app

The same policy applies from a subdirectory of the project. The tool still runs from the directory where you started the command.

Registry and version selection

LPM CLI supports npm, private registries configured through .npmrc, and LPM.dev Registry. Only @lpm.dev/* packages always use LPM.dev Registry. See registry configuration.

lpm dlx cowsay@1.6.0 -- "exact version"
lpm dlx cowsay@latest -- "registry tag"
lpm dlx cowsay -- "project selection or registry"

A bare package name can reuse that package's direct selection from the project lockfile. If the locked version satisfies a requested range, LPM CLI can reuse the direct selection. An explicit registry tag, such as latest or next, resolves that tag.

A lockfile selection carries its package version, source, and recorded integrity. The installed artifact must match that selection before dependency scripts or the package command can run. The command reports the actual selected version, integrity, and selection source.

Cache and refresh

The default cache is ~/.lpm/cache/dlx/. LPM_HOME changes the root. Entries remain fresh for 24 hours after a successful installation or refresh. Cache hits do not extend this period. Automatic cleanup scans stale entries at most once per hour, while the cache is idle.

Cache reuse must match the caller's registry and installation policy. Changed policy or routing requires a new validation before the command can run. Security approval checks still apply on a cache hit. If policy or authorization changes while the command waits for the cache, the command stops. Run it again after review. Custom TLS configuration, external policy programs, and advisor configuration require a fresh installation on each run.

lpm dlx --refresh create-next-app@latest -- my-app

--refresh resolves the requested selection again and prepares a replacement installation. A project lockfile selection remains pinned to its recorded identity. If refresh fails, the command fails and preserves the previous cache entry without extending its lifetime. It does not run the previous executable after that failure.

Concurrent commands retain the installation that they use. A replacement waits until active execution releases the entry. lpm cache prune --apply waits until the tool finishes and preserves packages in registered cache entries.

lpm cache path dlx
lpm cache clean dlx

See lpm cache for cache inspection and cleanup.

Executable selection

LPM CLI reads the installed package's bin metadata and ignores invalid executable names.

• If the package has one executable, the command uses it.
• If it has several executables, the command prefers the package's short name.
• If no unambiguous default exists, the command stops with an error.

For example, the short name of @scope/tool is tool. If the package exposes only one executable, its name can differ from the package name.

To select a different executable explicitly, install the package and use lpm exec.

Installation policy and command permissions

Installation uses the applicable release-age, integrity, provenance, and package policy checks from lpm install. The executable then runs with your user's filesystem and process permissions. The executable is not isolated from the current project's files.

LPM CLI removes inherited credential variables and protected runtime hooks before it starts an ordinary package tool. This environment filtering does not prevent the tool from reading accessible files or making network requests.

Release-age overrides

lpm dlx --min-release-age=3d create-next-app@latest -- my-app
lpm dlx --min-release-age-exclude create-next-app create-next-app@latest -- my-app
lpm dlx --allow-new create-next-app@latest -- my-app

--allow-new bypasses the cooldown for this invocation. --min-release-age=0 also requests a cooldown bypass. Overrides that weaken policy require interactive approval, as with lpm install. CI, --json, and non-interactive runs cannot approve these overrides.

Arguments and CI

lpm dlx prettier@3.6.2 -- --check src
lpm dlx tool -- --refresh --json
lpm --json dlx tool@1.0.0 -- --json

Put LPM CLI options before the package or before --. Put child options after -- to separate names that both programs recognize. The child's exit status determines whether execution succeeds. The tool controls its output and any prompts.

For CI, pin a version and pass the tool's own non-interactive options. A child --json flag controls the child's output. The global --json flag keeps installation output off stdout, including output from dependency scripts. LPM CLI does not wrap successful child output in a result object.

On Ctrl+C or a stop signal, LPM CLI stops the tool before it releases the cache entry.

Troubleshooting

Flags

See also

• lpm exec — installed tools and source files
• lpm install — project dependencies
• lpm global — persistent global tools
• lpm cache — cache inspection and cleanup
• Security audit — package checks and execution policy