A global npm install writes the package into the folder set by npm's prefix setting. By default that is the place Node itself is installed, often /usr/local on Unix systems and %AppData%\npm on Windows. Executables go on your PATH, so every terminal you open can run them with your user's permissions.
What "global" actually means
npm's own folder documentation puts it plainly: a local install goes into the node_modules folder of the current package root, while a global install goes into the prefix location. The advice in the same document is to install a package locally if you will require it from code, and globally if you will run it from the command line.
That second case is the one worth thinking about. A command line tool you install globally is not tied to any project. It is not in a lockfile, no pull request reviewed it, and no CI job scans it. It sits in one folder on one laptop and runs whenever you type its name.
Where to look on your own machine
You can ask npm directly instead of guessing. The prefix command prints the active prefix, and the root command with the global flag prints the global node_modules folder.
npm prefix -g
npm root -g
ls "$(npm prefix -g)/bin"
The last line lists the executables npm has linked into that prefix. Anything in that folder that is also on your PATH can be launched by name from any directory.
Why the location matters for safety
Three practical consequences follow from how the folder works.
- Global tools run with your full user privileges. They can read your home directory, including shell history, SSH keys and cloud credentials, unless something else restricts them.
- Global tools are invisible to project scanning. A scanner pointed at a repository reads that repository's manifests and lockfiles. It does not read your prefix folder.
- Global tools age quietly. Nobody gets a pull request when a tool you installed last year gains a security fix.
None of this means global installs are bad. It means they are a category of software on your laptop that you should be able to list and review.
A short review routine
- Print the prefix and list the global packages.
- For each one, ask whether you still use it. Remove what you do not.
- For what remains, note where it came from: the registry package name, the publisher, and the version.
- Check whether a one-off run through npx would do instead of a permanent install. Our post on what npx runs covers that trade-off.
- Schedule an update check. The companion post on updating global npm packages shows how.
How Safeguard fits
Safeguard's SBOM and dependency scanning covers the projects you build and ship. For a quick look at one of your own repositories, there is a free scan at gold.safeguard.sh/scan. Your global tools still need the manual review above.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory view and notice how each entry carries a source and version. Your global tools deserve the same record.
Quick check
Is a global npm package stored inside my project?
No. Per npm's folder documentation, a global install goes to the prefix location, not the project's node_modules folder.
Can I change where global packages go?
Yes. The prefix setting controls it, and npm documents changing the default directory as one fix for permission errors.
Sources
Last reviewed: 19 October 2026.
