Slow npm and Git in WSL Under /mnt/c

Linux tools accessing a project through the Windows-mounted filesystem can pay substantial cross-filesystem overhead, especially when many small files are involved. Compare an equivalent project inside the WSL Linux filesystem before changing hardware or disabling protection software.

Check both files and executables

Record the project path, WSL version and the locations of Node, npm and Git. A Linux shell can accidentally invoke a Windows executable through its PATH, adding another variable.

Microsoft's WSL version comparison recommends keeping files with the operating system whose tools work on them. The long-running upstream issue provides direct evidence of users encountering the cross-filesystem problem.

Those reports do not establish the same slowdown on every machine. Measure your own workload.

Design a fair comparison

Use a clean copy or clone with the same commit and dependency lockfile. Preserve your original working directory and uncommitted changes. Keep the same tool versions and commands.

Measure a small set of operations: Git status, dependency installation under comparable cache conditions, and the normal development build. Run more than once and separate first-run work from warm-cache work.

Location	Tool path	Cache condition	Command	Elapsed time
Windows-mounted path	Record	Record	Record	Measure
Linux filesystem	Same toolchain	Comparable	Same command	Measure

This worksheet contains no promised speedup.

Interpret differences cautiously

If many-file operations improve substantially but network downloads do not, storage access is a plausible contributor. If both locations remain slow, inspect CPU load, memory pressure, registry latency and the toolchain.

Do not copy an existing node_modules directory between incompatible operating systems and treat it as a clean comparison. Native dependencies can differ.

Keep your editor's remote-workflow support aligned with where the files live. Avoid manually modifying a distribution's internal storage through unsupported Windows paths.

Move deliberately if the test supports it

Use version control or a verified copy to move the project. Preserve local configuration, ignored files you need and pending changes. Reinstall dependencies with the intended Linux toolchain.

Keep the original until the project builds, runs and has the expected files. Update editor workspace paths and any scripts that assumed the old location.

Verify the real development task

Run the ordinary edit-build-test cycle, not just one filesystem benchmark. If an AI coding assistant watches the repository, verify that it sees changes and uses the correct environment.

The AI coding tools guide compares workflows. This diagnostic ensures filesystem placement is not distorting that comparison.

Related troubleshooting

• WSL Internet Fails on VPN: DNS or Routing?
• npm ci Fails but npm install Works

This guide draws on the linked documentation. Examples are illustrative unless explicitly identified as measured results.