‘The specified path… is too long’ on Windows
Verified on Windows 11, Node 24.20.0 · OpusMill
— or —
The specified path, file name, or both are too long.
Before you restructure anything, find out whether the 260-character limit even applies to your machine:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled
0x1 — long paths are on. The
260-character limit is not your problem and shortening
folder names will not fix it. Skip to
what else it could be.
0x0 or not found — the old limit
applies. See turning it on.
Why this is worth checking
The 260-character MAX_PATH limit is real history and it is
what most answers still assume. It has been opt-out since Windows 10
1607. On the machine I am writing this on it is already off, and I
measured what that means:
mkdir chain past 260 chars, then write and read a file at the end -> 422 characters, read back: hello reg query "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled -> LongPathsEnabled REG_DWORD 0x1
A 422-character path, created and read without complaint. Nothing was
shortened and no \\?\ prefix was used.
This is not a claim that you are fine. The setting is
opt-in and plenty of machines still have it at 0x0 —
it is likely on here because a developer tool enabled it during
installation, which is common but not universal. That is exactly why
the useful answer is a command you run rather than a fact you inherit
from me.
If it is 0x0
You can turn it on, from an administrator prompt:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" ^ /v LongPathsEnabled /t REG_DWORD /d 1 /f
Then restart — and know the two catches:
- An application must also opt in, via a manifest entry. Node does. Some older tools in your toolchain may not, and they will keep failing at 260 characters on the same machine.
- cmd.exe is not long-path aware. A build step that shells out can still fail where Node itself succeeds — which looks baffling until you know it.
If you cannot change the machine (a locked-down build agent, a
colleague's laptop), the portable answer is to stop generating deep
paths: shorten the checkout directory, and prefer
C:\src\proj over a nested path under Documents.
If long paths are already on, what else is it?
-
A single path component over 255 characters.
That limit is the filesystem's and
LongPathsEnableddoes not lift it. Usually a generated filename — a hash, a base64 blob, a concatenated cache key. -
A tool in the chain that is not long-path aware,
including anything invoked through
cmd.exe. - A network or mapped drive, where the limit is the server's and often lower.
- You are not on Windows at all. Linux caps a single component at 255 bytes, and bytes matters — a name of 80 emoji is over the limit while looking short.
Check your own project for the rest of this class of bug.
Paste your code or your package.json into
the browser checker — nothing is uploaded,
it runs on your machine — or run
npx github:Hackierz/winbreak over the whole repository.
--fix repairs the npm scripts that have one obvious
answer and refuses the ones that need a human.
Other errors in the same family:
- The fix for 'NODE_ENV' is not recognized
- The fix for 'rm' is not recognized
- The fix for spawn EINVAL on Windows
- The fix for ENOENT on node_modules/.bin
- EPERM on Windows
Background: I scanned the 600 most-downloaded
npm CLI packages — 17.4% have a package.json
script that cannot run on Windows.