npx runs a package binary. If the package is not in your project, npx downloads it from the registry into the npm cache and runs it, which means running someone else's code with your permissions. It asks first by default. Use the yes flag only for names you have already verified.
How npx decides what to run
The npm documentation says npx checks local dependencies first. A bare package name matches whatever version is installed locally. If a version is specified, it only matches a local dependency with that exact name and version.
If the package is not local, npx installs it into a folder in the npm cache and adds that folder to the PATH of the command it runs. That is a real install, including dependencies, and it can trigger lifecycle scripts like any other.
The prompt and the yes flag
Before installing, npx prints a prompt. The docs describe it as a safeguard against mistyped package names. The yes flag skips the prompt and proceeds. A no flag skips the prompt and does not install.
This matters because typosquatting depends on a rushed command. A single wrong letter in a copied snippet, run with the yes flag in a script, executes whatever sits under that name. See what typosquatting is in package registries.
Safer habits
- Prefer installing tools as devDependencies and running the local copy. The lockfile then pins them.
- Before running an unfamiliar package, look at its publisher and history using npm view, as described in is this npm package safe to install.
- Pin a version in the command instead of taking the latest.
- Keep the yes flag out of shared docs and CI unless the package name and version are fixed and reviewed.
- Run one-off tools in a throwaway container or a machine with no production credentials.
| Situation | Risk level | Suggested approach |
|---|---|---|
| Local devDependency | Lower | Run through npx or a package script |
| Pinned name and version, reviewed | Medium | Acceptable, with scripts reviewed |
| Unpinned name pasted from a chat or blog | Higher | Verify first, run in isolation |
Automation is where this gets worse. Agents and tools that launch servers through npx commands from configuration files run the same download-and-execute step with no human watching, so review those configs like code.
Common mistakes
Teams often copy an npx command from a README into a CI file and add the yes flag so it does not hang. That removes the one prompt designed to catch a mistyped name. Another habit is running the bare name with no version, which takes whatever the registry offers on the day. A third is running npx on a laptop that holds cloud keys and publish tokens, where one bad package can reach all of them. A short allowlist of approved tools, with versions, solves most of this.
Quick check
Does npx always download from the registry?
No. It uses a matching local dependency first. It downloads to the npm cache only when the package is not found locally.
What does the npx yes flag do?
It skips the confirmation prompt and proceeds with the installation.
Safeguard's MCP Guardrail and policies help control which tools agents can launch, and the free scan at gold.safeguard.sh/scan checks the dependencies in a project.
Sources
Last reviewed: 19 October 2026.
