Remote bin runner

Fetch a package from the registry and run its bin:

nub dlx create-vite my-app
nub x create-vite my-app                       # short alias
nub dlx -p cowsay -c 'cowsay hi | tr a-z A-Z'  # shell pipeline

Typing the command is itself the consent to download, so nub dlx fetches without a prompt and runs in CI. The short alias is nub x, mirroring bunx/bun x. Where nubx falls through to the registry implicitly — prompting on the first fetch, failing closed in CI — nub dlx never prompts. Both share the same persistent cache and registry safeguards.

-p, --package

When the bin name differs from the package name, name the package explicitly:

nub dlx -p @angular/cli ng new my-app

-c, --shell-mode

Run a shell one-liner with the fetched package's bin on PATH:

nub dlx -p cowsay -c 'cowsay hi | tr a-z A-Z'

--node

Run the fetched tool with runtime augmentation disabled — see the runtime overview for the full contract. The fetch, the cache, and the project's Node pin all still apply; only the augmentation is off.

nub dlx --node prisma generate
nub --node dlx prisma generate  # either side of the verb
nub dlx prisma generate --node  # past the tool name it's Prisma's flag, not Nub's

Lifecycle scripts

A fetched package's preinstall/install/postinstall scripts are skipped — downloading a tool is not consent to run its dependencies' build scripts. Approve a package with --allow-build=<pkg>, the same allowlist nub install uses.

Cooling window

A fetch runs through Nub's normal install resolver, so the minimumReleaseAge cooling window applies: a resolved version must be older than the window (default 24 hours) before it's used. See the cooling window for the full posture, including what happens when a registry serves no publish dates.

When the latest release is still inside the window, the tool runs at the newest release that clears it, and the substitution is reported — the scratch project is deleted when the tool exits, so this is the only record of which version ran:

$ nubx some-tool
+ some-tool@2.3.0  latest 2.4.0

warn: the latest some-tool release (2.4.0) is younger than minimumReleaseAge; using 2.3.0 instead
help: to take the newest release anyway: `--minimum-release-age=0`, or `--minimum-release-age-exclude=some-tool`

Naming a version instead (nubx some-tool@2.4.0) is a request for that exact release, so a blocked one fails rather than falling back.

Configuration

The global nub.jsonc carries a dlx block. Whether a tool may be pulled from the registry is a decision about your machine, so a project file cannot set it:

{
  // ...
  "dlx": {
    "consent": "never"  // no implicit nubx registry fetch
  }
}

Setting it to never turns off nubx's implicit fallthrough fetch; an explicit nub dlx still runs.

Related

• Runner — nubx, which fetches only on a local miss, and prompts first.
• Local bin runner — nub exec, for a tool that's already installed.
• Script runner — nub run, the package.json script runner.
• Package manager — installing dependencies for real, not just running them.