Introduction

If npm only works when you prefix commands with sudo, the problem is usually not npm itself. It is a permissions mismatch between your user account and the directories where Node, global packages, or the npm cache are installed.

The right fix is to stop npm from writing into root-owned locations for normal development. Reaching for sudo npm install may appear to work, but it tends to make the filesystem mess worse over time.

Why sudo Becomes Necessary

The usual pattern looks like this:

• Node was installed with a system package manager or a root-owned installer
• global npm packages try to install under a protected prefix such as /usr/local
• the npm cache may contain files created by sudo from earlier commands

Once that happens, ordinary npm commands can fail with permission errors such as EACCES.

You can inspect the current global install prefix with:

npm config get prefix

If that points to a system-owned directory, global installs are likely the issue.

Best Fix: Use a Node Version Manager

For most developers, the cleanest solution is to use a user-space Node installation with a version manager such as nvm. That keeps Node, npm, and global packages in your home directory rather than under system-owned paths.

After installing nvm, a typical flow looks like this:

1nvm install --lts
2nvm use --lts
3node -v
4npm -v

Now global installs happen under your user account:

npm install -g typescript

This is usually better than trying to repair a root-owned system installation indefinitely.

Alternative Fix: Change npm's Global Prefix

If you are keeping the current Node installation, move npm's global package prefix into a directory you own:

mkdir -p "$HOME/.npm-global"
npm config set prefix "$HOME/.npm-global"

Then add the binary directory to your shell path:

echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

For Bash, write the same line to ~/.bashrc or the profile file you actually use.

After that, test without sudo:

npm install -g eslint
which eslint

Clean Up a Broken Cache

If earlier sudo npm commands created root-owned files in the npm cache, you may still see failures even after fixing the prefix. Check the cache location:

npm config get cache

If it lives in your home directory, make sure you own it:

sudo chown -R "$(id -un)" "$(npm config get cache)"

Use this only to repair ownership of files that are supposed to belong to your user. Do not recursively change ownership of random system directories just to silence npm.

Prefer Local Project Dependencies When Possible

Many packages do not need global installation at all. Project dependencies belong in the project:

npm install --save-dev prettier
npx prettier --version

Using npx or project-local scripts reduces the need for global packages and therefore reduces permission trouble.

A Good Diagnostic Routine

When npm errors out, check these first:

1node -v
2npm -v
3npm config get prefix
4npm config get cache
5which node
6which npm

This tells you whether Node is coming from a version manager, a system install, Homebrew, or some other path. Mixed installations are a common source of confusion.

Common Pitfalls

The biggest mistake is normalizing sudo npm install -g ... as a routine workflow. That often creates more root-owned files and turns a small issue into a persistent one.

Another common problem is mixing multiple Node installations. If one shell resolves node from nvm but npm from a system package, behavior becomes inconsistent fast.

People also try to fix permissions by changing ownership of broad directories such as all of /usr/local. That can damage other tools. Repair only the npm-related locations you actually need.

Finally, remember that many tools do not need a global install. Local project dependencies plus npx are often simpler.

Summary

• npm permission errors usually come from root-owned install or cache paths.
• The cleanest fix is a user-space Node installation through a version manager such as nvm.
• If needed, move npm's global prefix into a directory under your home folder.
• Repair cache ownership only where npm is actually supposed to write.
• Avoid habitual sudo npm usage and prefer local dependencies when possible.