What does npm:EEXIST mean?

npm hit EEXIST because it tried to create a file or directory that already exists where npm expected to create a new one.

npm ERR! code EEXIST

Q: How do I prevent npm:EEXIST 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: npm tried to create a file, folder, lock, or global binary at a path that already exists.

1. Confirm this is your error

npm ERR! code EEXIST
npm ERR! errno EEXIST

2. Check the cause

ls -la <failing-path>
file <failing-path>
npm config get prefix
npm config get cache

3. Apply the safe fix

# Inspect the exact path from the error, then move only that conflicting file if it is stale.
mv <failing-path> <failing-path>.bak
npm install

# If the conflict is a global binary, uninstall or rename the old global package before reinstalling.

4. Verify it works

npm install
ls -la <failing-path>

Don't use unsafe shortcuts

Do not use --force before you know what existing file npm is protecting.
Do not remove broad folders like the whole project or npm prefix for a single EEXIST path.
Do not run the install as root to overwrite the conflict, that can create new permission problems.

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).

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

Why It Happens

The error output usually includes the path that failed, that path points to the real OS-level issue (permissions, disk, locks, or limits).

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

Look for the last referenced filesystem path in the error output and validate that path exists and is writable.

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
      }