Fix: npm ERR! cb() never called

The Error

When running npm install (or any npm command), you hit this cryptic error:

npm ERR! cb() never called!
npm ERR! not ok code 0

npm ERR! This is an error with npm itself. Please report this error at:
npm ERR!     <https://npm.community>

Or, in newer npm versions, you might see a slightly different format:

npm ERR! cb() never called!

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/user/.npm/_logs/2026-06-06T12_00_00_000Z-debug-0.log

Unlike most npm errors that point to a specific package or configuration problem, this one gives you almost nothing to work with. The cb() refers to an internal callback function inside npm that was expected to execute but never did. Something interrupted npm’s process before it could finish.

Why This Happens

The “cb() never called” error is npm’s generic way of saying “something went wrong internally, and I don’t know what.” It is not a single bug — it is a symptom that can be triggered by multiple underlying causes.

The most common triggers are:

1. Corrupted npm cache. npm stores downloaded packages in a local cache (~/.npm on Linux/macOS, %AppData%\npm-cache on Windows). If files in this cache are incomplete or corrupted — from a previous interrupted install, a disk issue, or even an npm bug — npm may fail silently and never invoke its completion callback.

2. Network interruptions. A flaky connection, corporate proxy, VPN timeout, or DNS resolution failure can cause npm to hang while downloading a package. When the connection drops mid-download, npm sometimes fails to handle the error gracefully and surfaces this callback error instead.

3. Corrupted package-lock.json. The lockfile can get into an inconsistent state after merge conflicts, manual edits, or interrupted installs. When npm tries to resolve dependencies from a malformed lockfile, it can enter an unrecoverable state.

4. Outdated npm version. Older npm versions (especially npm 5.x and early 6.x) had bugs that directly caused this error. Many of these were fixed in later releases.

5. File system permission issues. npm needs write access to node_modules, the cache directory, and temporary directories. Permission problems can cause silent failures.

6. Disk space exhaustion. If the disk fills up during installation, write operations fail and npm cannot complete its internal callbacks.

7. Node.js and npm version incompatibility. Running a version of npm that was not designed for your current Node.js runtime can cause unexpected internal failures.

Let’s fix it, starting with the most likely solutions.

Fix 1: Clear the npm Cache

This resolves the error in the majority of cases. A corrupted cache is the single most common cause of “cb() never called.”

npm cache clean --force

The --force flag is required since npm 5. Without it, npm refuses to clean the cache because it is supposed to be self-healing. In practice, the self-healing mechanism does not always work.

After clearing the cache, retry your install:

npm install

If you want to verify the cache integrity before clearing it (to confirm corruption is the issue):

npm cache verify

This will report any corrupted entries and attempt to fix them. If it reports issues, follow up with the full npm cache clean --force.

Fix 2: Delete node_modules and package-lock.json

If clearing the cache alone didn’t work, the problem may be in your project’s existing dependency tree. Remove everything and start fresh:

rm -rf node_modules package-lock.json
npm cache clean --force
npm install

On Windows (Command Prompt):

rmdir /s /q node_modules
del package-lock.json
npm cache clean --force
npm install

This three-step approach eliminates corrupted cached packages, stale lockfile entries, and partially installed modules all at once. It is the most thorough local fix.

Common Mistake: Deleting node_modules but leaving package-lock.json in place. If the lockfile itself is corrupted or contains stale resolution data, npm will try to follow the same broken resolution path again. Always remove both when troubleshooting this error.

Fix 3: Update npm

Many “cb() never called” occurrences were caused by bugs in npm itself that were fixed in later versions. Update npm to the latest release:

npm install -g npm@latest

Check your current version before and after:

npm --version

If you are on npm 5.x or early 6.x, upgrading is especially important. These versions had known issues with callback handling during network failures and cache operations.

If the global install itself fails with the same error, you can update npm through Node.js instead:

# Install nvm (Node Version Manager) if you don't have it
# Then install the latest LTS Node.js, which includes a recent npm
nvm install --lts
nvm use --lts

If you get permission errors during global npm installs, see Fix: EACCES permission denied when installing npm packages globally for the proper fix — don’t use sudo.

Fix 4: Fix Network and Proxy Issues

Network problems are the second most common cause. npm might hang on a download, time out, and then fail with the callback error.

Test your connection to the npm registry:

npm ping

If this times out or fails, you have a network issue.

If you are behind a corporate proxy:

npm config set proxy http://your-proxy-server:port
npm config set https-proxy http://your-proxy-server:port

If a proxy was set but you don’t need one (common after switching from a corporate to a personal network):

npm config delete proxy
npm config delete https-proxy

If you suspect SSL issues (common behind corporate firewalls that perform SSL inspection):

npm config set strict-ssl false

Only use this as a diagnostic step. If it fixes the issue, talk to your network team about adding the npm registry’s certificate to your trusted certificates rather than disabling SSL verification permanently.

Increase the network timeout if you are on a slow connection:

npm config set fetch-retry-mintimeout 20000
npm config set fetch-retry-maxtimeout 120000
npm config set fetch-retries 5

These settings give npm more time and more attempts to complete downloads before giving up.

Fix 5: Switch the npm Registry

The default npm registry (https://registry.npmjs.org/) may be experiencing issues, or your network may be blocking it. Try switching to a mirror:

# Check current registry
npm config get registry

# Switch to a mirror (example: npmmirror for users in China)
npm config set registry https://registry.npmmirror.com/

# Or use the Yarn registry as an alternative
npm config set registry https://registry.yarnpkg.com/

After testing, if the mirror works, the problem is either with the default registry or with your network’s connection to it. You can switch back after the issue resolves:

npm config set registry https://registry.npmjs.org/

If you are using a private registry (Artifactory, Verdaccio, GitHub Packages) and getting this error, verify that the registry is accessible and your authentication tokens are valid:

npm whoami --registry https://your-private-registry.com/

Fix 6: Check Disk Space

npm needs space for downloading packages, extracting them, and writing to node_modules. If your disk is full, npm will fail in unexpected ways — including the callback error.

# Linux/macOS
df -h

# Windows (PowerShell)
Get-PSDrive C

A typical node_modules folder can be hundreds of megabytes to several gigabytes. Make sure you have at least 1-2 GB of free space.

If space is tight, clean up old npm caches and unused node_modules directories:

# Clear npm cache
npm cache clean --force

# Find large node_modules directories (Linux/macOS)
du -sh ~/projects/*/node_modules 2>/dev/null | sort -hr | head -20

This situation is also common in Docker containers with limited disk space. If you are hitting this in a Docker build, see the CI/CD section below. For other Docker disk space issues, Fix: Docker no space left on device covers the broader problem.

Fix 7: Fix Node.js Version Compatibility

Certain npm versions do not work correctly with certain Node.js versions. This mismatch can cause internal errors including the callback issue.

Check your current versions:

node --version
npm --version

The general rule: use the npm version that ships with your Node.js version. You can check which npm version comes with which Node.js release at the Node.js releases page.

If you have manually upgraded or downgraded npm independently of Node.js, you may have introduced a compatibility issue. Reset to the bundled version:

# If using nvm
nvm install-latest-npm

# If not using nvm, reinstall Node.js from nodejs.org
# This will restore the matching npm version

Pro Tip: Use a .nvmrc or .node-version file in your project root to pin the Node.js version across your team. This prevents “works on my machine” issues caused by version mismatches. Create it with node --version > .nvmrc and team members can simply run nvm use to switch to the correct version.

Using a version manager like nvm (Linux/macOS) or nvm-windows also prevents the EACCES permission errors that come from installing Node.js system-wide.

Fix 8: Handle package-lock.json Corruption

The lockfile can become corrupted in several ways: merge conflicts that were resolved incorrectly, manual edits that broke the JSON structure, or interrupted npm install runs that left the file in a partial state.

Signs of lockfile corruption:

• The file has merge conflict markers (<<<<<<<, =======, >>>>>>>)
• The JSON is malformed (missing brackets, trailing commas)
• Integrity hashes are mismatched or missing

Regenerate the lockfile:

rm package-lock.json
npm install

If your project uses npm ci in production or CI (which requires a lockfile), make sure to commit the newly generated package-lock.json.

If you hit merge conflicts in package-lock.json during a git merge or rebase, the safest resolution is almost always to delete the lockfile and regenerate it rather than trying to resolve the conflicts manually. The lockfile is auto-generated — treat it that way:

# After a merge conflict in package-lock.json
git checkout --theirs package-lock.json
rm package-lock.json
npm install
git add package-lock.json

This accepts the incoming version, immediately discards it, and regenerates the file based on the merged package.json. If you are dealing with more general merge conflict issues, see Fix: Git merge conflicts for the full workflow.

Fix 9: Fix Permissions

On Linux and macOS, permission issues with npm’s cache directory or global install directory can cause silent failures.

Check ownership of the npm cache:

ls -la ~/.npm

If the directory is owned by root (which happens if you’ve ever run npm install with sudo), fix the ownership:

sudo chown -R $(whoami) ~/.npm

Check the temporary directory. npm uses the system temp directory during installs. If it is not writable:

# Check the temp directory npm is using
npm config get tmp

# Make sure it is writable
ls -la $(npm config get tmp)

On Windows, permission issues are less common but can occur if you are running your terminal without the required access level or if antivirus software is blocking npm from writing to node_modules.

Fix 10: Fix Issues in CI/CD Environments

The “cb() never called” error is disproportionately common in CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins, CircleCI) due to resource constraints and network conditions.

Use npm ci instead of npm install:

npm ci

npm ci is designed for automated environments. It deletes node_modules before installing, installs exact versions from the lockfile (no resolution needed), and is faster and more deterministic. It is less likely to trigger the callback error because it skips the dependency resolution step that often causes the problem.

Add retry logic in your CI configuration:

# GitHub Actions example
- name: Install dependencies
  run: |
    for i in 1 2 3; do
      npm ci && break || {
        echo "npm ci failed, attempt $i/3"
        npm cache clean --force
        sleep 10
      }
    done

Increase memory for Node.js if your CI runner has limited RAM:

export NODE_OPTIONS="--max-old-space-size=4096"
npm ci

Cache node_modules between CI runs to reduce network dependency. Most CI platforms have built-in caching mechanisms:

# GitHub Actions example
- name: Cache node modules
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

If your CI builds also fail with exit code errors, Fix: npm ERR! code ELIFECYCLE covers those related scenarios.

Fix 11: Use a Different Package Manager

If nothing else works and you need to move forward, try installing dependencies with a different package manager. Both yarn and pnpm use different caching and resolution mechanisms, which often sidestep whatever is causing npm’s callback failure.

Try Yarn:

# Install Yarn
npm install -g yarn

# Install dependencies
yarn install

Try pnpm:

# Install pnpm
npm install -g pnpm

# Install dependencies
pnpm install

You don’t have to permanently switch your project to a different package manager. This is a diagnostic step — if yarn or pnpm installs successfully, it confirms the problem is specific to npm’s internal handling rather than your packages or network. You can continue using the resulting node_modules while you investigate the npm issue further.

Fix 12: Reinstall Node.js Completely

If you have tried everything above and the error persists across multiple projects, the problem may be with your Node.js and npm installation itself.

On macOS/Linux with nvm:

# List installed versions
nvm ls

# Uninstall the problematic version
nvm uninstall 18.17.0

# Install fresh
nvm install 18
nvm use 18

On Windows:

1. Uninstall Node.js from “Add or Remove Programs”
2. Delete the following directories if they exist:
   • C:\Users\<your-user>\AppData\Roaming\npm
   • C:\Users\<your-user>\AppData\Roaming\npm-cache
   • C:\Users\<your-user>\.npmrc (if present and you don’t have custom settings you need)
3. Download and install Node.js fresh from nodejs.org

On Linux without nvm:

# Remove existing installation
sudo apt-get purge nodejs npm
sudo rm -rf /usr/local/lib/node_modules
sudo rm -rf ~/.npm

# Install fresh using NodeSource
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs

After a fresh install, verify both versions and test with a clean project:

node --version
npm --version
mkdir /tmp/test-npm && cd /tmp/test-npm
npm init -y
npm install express

If this simple install works, the issue is project-specific. If it still fails, the problem is environmental (network, permissions, disk).

Still Not Working?

1. Read the debug log. The error output includes a path to a log file (e.g., ~/.npm/_logs/2026-06-06T12_00_00_000Z-debug-0.log). Open this file — it contains the full trace of what npm was doing when it failed. Look for network errors, permission denied messages, or specific package names that failed to download.

2. Run npm with verbose logging:

   npm install --verbose

   This prints every HTTP request, cache lookup, and file operation in real time. Watch for where it stalls or errors out.

3. Test with a minimal project. Create an empty directory, run npm init -y, and try installing a single package. If that works, the problem is specific to your project’s dependency tree. If it fails, the problem is environmental.

4. Check for antivirus interference. On Windows, antivirus software (including Windows Defender) can lock files that npm is trying to write, causing the callback to never complete. Try temporarily disabling real-time scanning and retrying the install.

5. Check if npm scripts are hanging. If a package has a postinstall script that hangs (waiting for input, stuck in an infinite loop, or failing silently), npm may report the callback error. Run with --ignore-scripts to test:

   npm install --ignore-scripts

   If this succeeds, one of your dependencies has a problematic install script. You can identify which one by checking npm ls and looking for packages known to have postinstall scripts (native modules like node-sass, sharp, or bcrypt are common culprits). For problems caused specifically by lifecycle script failures, see Fix: npm ERR! code ELIFECYCLE.

Related: If npm installs succeed but you get module resolution errors afterward, see Fix: Error Cannot find module. If you are hitting dependency tree conflicts instead, see Fix: npm ERESOLVE unable to resolve dependency tree.