[BUG] Startup scan recurses into node_modules despite .gitignore, causing multi-minute hang on WSL2 /mnt/c projects

Status Open
Reported on v2.1.252
Maintainer reply None cached
Activity 0 comments · opened Sep 1, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

On WSL2, starting a first Claude Code session in a project located on /mnt/c/... takes several minutes, with the input box appearing frozen the whole time.

I traced the process with strace -f -tt -T -o claude.trace claude --model haiku -p "hi" --verbose and found the startup directory scan (main thread) recursively walks the entire project tree, including node_modules, even though node_modules/ and **/node_modules/ are both listed in the project's .gitignore.

Trace Metrics (Main Thread Syscall Counts):

openat (directory open): 30,352

getdents64 (read dir entries): 60,886

close: 30,301

Note: 24,542 of the 30,352 openat calls (81%) are inside node_modules.

Performance Impact:
Each of these syscalls averages ~5–8ms on WSL2's /mnt/c (9p-mounted Windows filesystem), vs. sub-0.1ms on native ext4. Tens of thousands of extra calls into an ignored directory account for the multi-minute delay (trace wall time: ~5 minutes).

What Should Happen?

I'm not asserting this should follow any specific documented ignore-mechanism (I checked — Glob does not respect .gitignore by default, Grep does, and startup-scan behavior isn't documented either way). What I'm reporting is purely the observed impact: the startup scan spending 81% of its directory-open calls inside node_modules, and taking ~5 minutes on WSL2's /mnt/c, seems unintentional regardless of ignore-file semantics. At minimum, a way to skip known-huge, rarely-relevant directories like node_modules during this specific startup walk (independent of Glob/Grep's own ignore behavior) would fix this.

Error Messages/Logs

(no error thrown — silent performance issue)

Supporting evidence from strace:
openat calls total:        30352
of which under node_modules: 24542 (81%)
getdents64 calls total:    60886
close calls total:         30301
trace wall-clock duration: ~5 minutes (09:25:05–09:30:03)

Steps to Reproduce

  1. On WSL2, place a frontend project with a large node_modules

(tens of thousands of files/dirs) under /mnt/c/... (a Windows
filesystem path, not the WSL native ext4 filesystem).

  1. Confirm the project's .gitignore contains node_modules/.
  2. In that directory, run:

strace -f -tt -T -o claude.trace claude --model haiku -p "hi" --verbose

  1. Observe the CLI takes multiple minutes to respond; the input

box appears stuck the whole time.

  1. Inspect the trace:

grep -c node_modules claude.trace
-> tens of thousands of hits, almost all openat() calls on the
main thread walking into node_modules despite .gitignore.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.252 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Windows Terminal

Additional Information

Related: #29672 describes a different WSL2 slowness (repeated powershell.exe spawns to resolve USERPROFILE). That issue is already mitigated on my machine via the .bashrc workaround; the node_modules scan issue described here is separate and still reproduces.

claude-trace-sample-sanitized.txt

View original on GitHub ↗