What does npm:EBUSY mean?

npm hit EBUSY because a file or directory was locked or still in use by another process, editor, antivirus tool, or sync service.

npm ERR! code EBUSY

Q: How do I prevent npm:EBUSY in CI?

Keep npm cache and project directories owned by the build user. Avoid running project installs as root unless you know exactly why you need it. Ensure CI runners have enough disk space and sensible file descriptor limits.

Fix it fast

Most likely: A file or folder npm needs is locked by another process, such as a dev server, watcher, editor, antivirus tool, sync tool, or another npm install.

1. Confirm this is your error

npm ERR! code EBUSY
crashes in CI with an EBUSY error when it tries to read

2. Check the cause

npm config get cache
lsof +D <failing-directory>
ps aux | grep npm
ls -la <failing-path>

3. Apply the safe fix

# Stop the process that is holding the failing path, then verify npm's cache.
npm cache verify
npm install

# On Windows, close editors/watchers and reboot if the lock does not clear.

4. Verify it works

npm install
npm cache verify

Don't use unsafe shortcuts

Do not run multiple npm install commands against the same project at the same time.
Do not use sudo to bypass a file lock, it usually creates ownership problems instead.
Do not remove project folders until you know which process is holding the path.

What This Error Means

Read this as a precise clue about which part of the workflow broke first. Once you know the failing layer, the fix path gets much shorter.

How to Fix It

Identify the path npm is failing on (look for the last referenced file path in the error output).

Close editors/processes that may lock files (watchers, antivirus), then retry. On Windows, a reboot sometimes clears locks.

Retry after cleaning local state when safe (common:remove node_modules and retry install).

Why It Happens

A background process is locking files while npm is trying to rename/remove them.

Verify the Fix

Re-run the original command and confirm the filesystem error no longer appears.

If this is a permission fix, confirm new files in node_modules are owned by the expected user.

Manual filesystem checks

If a directory removal fails, confirm no process is using it (platform-specific:lsof +D <dir>).

How npm writes files during install

This is the part worth understanding if the quick fix did not hold. It explains what npm is trying to do at the moment the error appears.

npm is reporting a failure at a specific layer of the workflow:local environment, configuration, remote service access, or artifact metadata.

The fastest path is to identify which layer broke first, then verify that layer directly instead of retrying the same high-level command and hoping for a different result.

Prevent It From Coming Back

To prevent this, keep npm cache and project directories owned by the build user, avoid running project installs as root unless you know exactly why you need it, and ensure CI runners have enough disk space and sensible file descriptor limits.

Docs and source code

github.com/npm/cli/blob/417daa72b09c5129e7390cd12743ef31bf3ddb83/workspaces/libnpmexec/lib/with-lock.js

Open-source npm CLI code reference tied to this error code. - GitHub

    try {
      await fs.mkdir(lockPath)
    } catch (err) {
      if (err.code !== 'EEXIST' && err.code !== 'EBUSY' && err.code !== 'EPERM') {
        throw err
      }