Fix: EBUSY: resource busy or locked (npm, Windows)

Windows won’t delete a folder or file that something else is using. When npm (or a Node script) tries to, it stops with EBUSY or, just as often, EPERM. The path in the error tells you what is locked; the cause is always another process, and it’s usually one you started yourself: a dev server, a watcher, a terminal tab.

I reproduced both on Windows 11 with Node 24.14.0 and npm 11.9.0, in a project with esbuild and sharp installed, by keeping something busy and running npm ci, which deletes node_modules first.

So if your message says EPERM … unlink on an .exe, .dll or .node file, it’s the same problem as EBUSY, and the same fix.

1. A terminal or process sitting inside the folder (EBUSY rmdir)

With a process whose working directory was node_modules\esbuild, npm ci failed with:

npm error code EBUSY
npm error syscall rmdir
npm error path D:\nk-ebusy\proj\node_modules\esbuild
npm error errno -4082
npm error EBUSY: resource busy or locked, rmdir 'D:\nk-ebusy\proj\node_modules\esbuild'

That’s what happens when a terminal tab is cd’d into that folder, or a dev server or script was started from inside it. Windows treats a process’s current folder as in use.

Get-CimInstance Win32_Process -Filter "Name='node.exe'" | Select-Object ProcessId, CommandLine

Stop-Process -Id <ProcessId>

2. A program from node_modules still running (EPERM unlink)

Dev servers often run a native program straight from node_modules, like esbuild’s esbuild.exe. While it ran, npm ci couldn’t delete it:

npm error code EPERM
npm error syscall unlink
npm error path D:\nk-ebusy\proj\node_modules\@esbuild\win32-x64\esbuild.exe
npm error errno -4048

A Node process that had loaded sharp blocked it the same way, on libvips-42.dll. Native modules (.node files and their DLLs) stay locked for as long as any process has them loaded.

Get-Process node | Where-Object { $_.Modules.FileName -like '*\your-project\node_modules\*' } | Select-Object Id, ProcessName

What didn’t work

How this was tested

Windows 11 Pro, Node 24.14.0, npm 11.9.0, October 15, 2026. A fresh project with esbuild 0.28.2 and sharp installed. For each case a separate process was started with PowerShell’s Start-Process (an esbuild --serve server, a Node script that loads sharp, and an idle Node process whose working directory was inside node_modules), then npm ci or Node’s fs.rmSync ran against the same folder, and finally the process was stopped by its ID and the command repeated. Every error above is the real output.

November 2, 2026: all three causes were re-run on GitHub Actions windows-latest (Windows Server 2025, Node 24.22.1, npm 11.19.1, esbuild 0.28.2, sharp 0.35.5). A process started inside node_modules\esbuild gave EBUSY / rmdir / -4082; a running esbuild.exe gave EPERM / unlink / -4048 on esbuild.exe, and fs.rmSync with maxRetries: 3 failed too; a Node process with sharp loaded gave EPERM on libvips-42.dll. Both PowerShell commands found the right process, and npm ci finished each time once it was stopped. The script and output are public.