Skip to content

File tree subtree builder scans gitignored directories (node_modules, .next) before applying gitignore filter, causing excessive resource usage #8754

@it-all-playpark

Description

@it-all-playpark

File tree subtree builder scans gitignored directories (node_modules, .next) before applying gitignore filter, causing excessive resource usage

Description

Warp's file tree / project explorer appears to traverse directories before applying .gitignore exclusion rules. This causes thousands of Failed to build subtree warnings when working with projects that use pnpm (which creates extensive symlink trees inside node_modules).

Even though node_modules/ and .next/ are listed in .gitignore and correctly hidden from the file tree UI, the underlying subtree builder still attempts to walk into these directories and resolve their symlinks.

Environment

  • Warp version: v0.2026.02.18.08.22.stable_02
  • OS: macOS 26.3 (Darwin 25.3.0), Apple Silicon
  • Package manager: pnpm (uses symlinks extensively inside node_modules/.pnpm/)
  • Project structure: monorepo with multiple git worktrees

Reproduction

  1. Create a monorepo using pnpm (e.g., Next.js + multiple packages)
  2. Run pnpm install so node_modules/.pnpm/ is populated with symlinks
  3. Optionally run next build to generate .next/standalone/ (which also contains node_modules with symlinks)
  4. Create multiple git worktrees, each with their own node_modules
  5. Open Warp and navigate to the worktree directories
  6. Observe warp.log (~/Library/Logs/warp.log)

Evidence from logs

On a single day, warp.log recorded 2,851 Failed to build subtree warnings, with 2,629 concentrated in a single hour.

Sample log entries:

2026-02-24T00:31:53Z [WARN] Failed to build subtree for directory ".../node_modules/.pnpm/node_modules/react": Symlink
2026-02-24T00:31:53Z [WARN] Failed to build subtree for directory ".../node_modules/.pnpm/next@15.5.7_.../node_modules/react": Symlink
2026-02-24T00:31:53Z [WARN] Failed to build subtree for directory ".../node_modules/.pnpm/styled-jsx@5.1.6_.../node_modules/client-only": Symlink
2026-02-24T00:31:53Z [WARN] Failed to build subtree for directory ".../node_modules/.pnpm/react-dom@19.1.2_.../node_modules/react": Symlink

All 2,851 warnings target paths inside node_modules/ or .next/standalone/node_modules/ — directories that are in .gitignore and should never be scanned.

Why pnpm makes this worse

pnpm uses a content-addressable store with symlinks to represent package dependencies:

node_modules/.pnpm/next@15.5.7_.../node_modules/
  next/              ← actual package
  react -> ../../react@19.1.2/node_modules/react          ← symlink
  postcss -> ../../postcss@8.4.31/node_modules/postcss     ← symlink
  styled-jsx -> ../../styled-jsx@5.1.6_.../node_modules/.. ← symlink

Each package has symlinks to its dependencies, creating a deep graph. When the subtree builder walks into node_modules/.pnpm/, it encounters hundreds of symlinks, each triggering a warning.

Why git worktrees make this worse

Each worktree has its own node_modules/ (created by pnpm install). With N worktrees, the scanning is multiplied N times. In our case, 2 active worktrees with node_modules + .next/standalone = thousands of unnecessary scan attempts.

Expected behavior

Directories matching .gitignore patterns (e.g., node_modules/, .next/) should be skipped entirely during the subtree building phase — not just filtered from the UI display.

Suggested fix

Apply .gitignore exclusion rules before (or at the entry point of) directory traversal in the subtree builder, so that gitignored directories are never entered or scanned. This would:

  1. Eliminate all Failed to build subtree warnings for gitignored paths
  2. Reduce memory usage and CPU overhead from scanning large symlink trees
  3. Improve performance for pnpm-based monorepos with multiple worktrees

Workaround

Currently the only workarounds are:

  • Close the file tree panel when not needed
  • Delete unused worktrees to reduce scan targets
  • Set AgentModeCodebaseContextAutoIndexing to false (disables Agent context indexing)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions