Windows 11: Warp v0.2026.03.18.08.24.stable_03 grows to ~30 GB committed memory while scanning .output/server/node_modules symlink tree

[King-GD]

Pre-submit Checks

• I have searched Warp bugs and there are no exact duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix).
• I have technical issue and have included the logs (optional, but helps expedite the bug fix).

Describe the bug

On Windows 11, Warp v0.2026.03.18.08.24.stable_03 can become extremely slow and consume very large amounts of memory while working in a local project that contains generated directories with symlinks under .output/server/node_modules/....

In my case, warp.exe reached about:

• 5.8 GB working set
• ~30 GB committed/private memory shown by Task Manager / process metrics

At that point Warp became very laggy.

This looks related to background project scanning / codebase indexing, not to Warp's own on-disk cache size. Warp local app data was only about 182 MB total.

To reproduce

I do not have a fully minimal repro yet, but the issue was observed with this pattern:

1. Open Warp on Windows 11
2. Open a local project directory
3. The project contains generated output under .output/server/node_modules/...
4. That tree contains multiple symlinks/junction-like entries (for example Vue/Nitro/VueUse related packages)
5. Continue normal terminal usage in Warp
6. Warp becomes increasingly laggy and memory usage grows very large

Expected behavior

• Warp should not consume multi-gigabyte memory for background project scanning/indexing
• Symlink-heavy generated folders should be skipped safely or handled without runaway memory growth
• Warp should remain responsive while working in normal local repositories

Screenshots, videos, and logs

I do not have screenshots attached yet, but I captured the following local evidence.

Environment:

• OS: Windows 11 Pro (10.0.26200)
• Shell: PowerShell 7.6.0
• Warp version: v0.2026.03.18.08.24.stable_03
• Date observed: 2026-03-25

Observed process metrics:

• Main warp.exe working set: about 5.8 GB
• Main warp.exe committed/private memory: about 30 GB
• Warp local data directory size: about 182 MB

Relevant log excerpts from warp.log:

2026-03-25T07:40:21Z [INFO] Already up to date with v0.2026.03.18.08.24.stable_03
2026-03-25T07:40:38Z [WARN] Failed to build subtree for directory "<redacted-workspace>\\.output\\server\\node_modules\\element-plus\\node_modules\\@vueuse\\core": Symlink
2026-03-25T07:40:38Z [WARN] Failed to build subtree for directory "<redacted-workspace>\\.output\\server\\node_modules\\@vueuse\\shared": Symlink
2026-03-25T07:40:38Z [WARN] Failed to build subtree for directory "<redacted-workspace>\\.output\\server\\node_modules\\.nitro\\@vueuse\\core@9.13.0\\node_modules\\@vueuse\\shared": Symlink
2026-03-25T07:40:38Z [WARN] Failed to build subtree for directory "<redacted-workspace>\\.output\\server\\node_modules\\.nitro\\@vueuse\\core@14.1.0\\node_modules\\@vueuse\\shared": Symlink
2026-03-25T07:40:38Z [WARN] Failed to build subtree for directory "<redacted-workspace>\\.output\\server\\node_modules\\pinia\\node_modules\\@vue\\devtools-api": Symlink
2026-03-25T07:40:38Z [WARN] Failed to build subtree for directory "<redacted-workspace>\\.output\\server\\node_modules\\@vue\\devtools-api": Symlink
2026-03-25T07:40:38Z [WARN] Failed to build subtree for directory "<redacted-workspace>\\.output\\server\\node_modules\\@vueuse\\core": Symlink
2026-03-25T07:43:05Z [WARN] Failed to build subtree for directory "<redacted-workspace>\\.output\\server\\node_modules\\vue-router\\node_modules\\@vue\\devtools-api": Symlink
2026-03-25T07:43:05Z [WARN] Failed to build subtree for directory "<redacted-workspace>\\.output\\server\\node_modules\\@vue\\devtools-api": Symlink

Project tree characteristics observed locally:

• .output total size: about 45.36 MB
• .output total item count: 4553
• Several symlink/reparse-point entries exist under .output/server/node_modules

Operating system (OS)

Windows

Operating system and version

Windows 11 Pro (10.0.26200)

Shell Version

PowerShell 7.6.0

Current Warp version

v0.2026.03.18.08.24.stable_03

Regression

Possibly yes. The Warp install directory on this machine was updated on 2026-03-24, and the issue was noticed on 2026-03-25.

Recent working Warp date

2026-03-24 or earlier. I did not capture the exact last-known-good version before this regression.

Additional context

This may be related to existing Windows resource issues, but this report seems narrower and more actionable because the logs repeatedly show subtree-building failures on symlinked generated directories inside the active project.

Possibly related issues:

• Windows: Runaway Git indexing and Tree-sitter parsing cause extreme memory/disk usage and prevent Warp from exiting #8545
• memory leak in windows, using codex or claude #8822
• High Memory Usage #2611

A useful mitigation on your side might be to exclude generated output folders like .output from project/codebase scanning on Windows, or to hard-stop recursive subtree building when symlinked directories are encountered.

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

[zachbai]

Thanks for the detailed report, the provided info is super helpful.

@acarl005 can you take a look?

[kevinchevalier]

Thanks for the report. This is a high priority bug that we are investigating. Is this fairly reproducible for you?

If so, does disabling codebase indexing seem to fix the issue?

I'm continuing to look into this, and will keep you updated on the progress.

[King-GD]

@kevinchevalier
Disabling codebase indexing did not fix the issue.
I also found another reliably reproducible case: in Warp, when using Codex to restore previous conversation history, memory usage spikes significantly. This happens consistently, and the longer the conversation gets, the higher the memory usage climbs.