Fix: git 'Filename too long' on Windows (clone, checkout)

Windows historically limits a full file path to 260 characters. Git for Windows keeps that limit by default, even when Windows itself would allow longer paths. A repository with deep folders (a committed node_modules, generated code, a monorepo nested inside another folder) passes the limit, and the clone stops half-way:

error: unable to create file node_modules/@some-scope/…/an-equally-long-file-name-for-the-generated-component-module.js: Filename too long
fatal: unable to checkout working tree

My test repository had one file whose full path was 286 characters. The clone created the repository but not the files: git status then showed that file as deleted.

Clone with long paths on

git clone -c core.longpaths=true <url>

git config --global core.longpaths true

Rescue a clone that already failed

No need to clone again. Inside the half-checked-out repository:

git config core.longpaths true
git restore --source=HEAD --staged --worktree :/

A long file name gives a different error

The 260-character limit is about the whole path. A single file or folder name over 255 characters is a separate limit, and on Windows Node didn’t report it as “too long”: writing a 256-character file name failed with

ENOENT: no such file or directory, open 'D:\nk-longpath\xxxx…'

A 250-character name worked. If you see ENOENT for a file you’re creating (not reading), check the length of its name.

How this was tested

Windows 11 Pro with Git for Windows and Node 24.14.0, October 18, 2026. A local repository with one file at a 286-character path was committed with long paths on, then cloned into a fresh folder with default settings and with long paths on, and repaired after a failed clone as shown. Long names were tested with Node’s fs.writeFileSync at 250, 256 and 300 characters. No global git settings or Windows settings were changed for the test. Every message above is the real output.