Warp failing to index large codebase bc file tree building stage `ExceededMaxFileLimit` before `.warpindexingignore` is applied

[batpigandme]

Pre-submit Checks

• I have searched Warp bugs and there are no 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). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

Can no longer index large codebase because file tree building stage happens before .warpindexingignore is applied.

I've work in a large monorepo (stdlib-js/stdlib) that was indexed successfully in Warp until recently when I started getting ExceededMaxFileLimit when syncing.

I went in to see how I could cut down the files warp was trying to index with the AI agent (full agent conversation here and was cutting and cutting with .warpindexingignore, but kept getting the same Codebase too large issue when re-syncing.

After cutting the file count well below 100,000 (I have the Basic plan, so ~79,000 files should've been fine), I finally asked the Agent to figure out what Warp thought my file count was and it came back with:

The logs reveal the key issue. 
Warp is failing at the file tree building stage with `ExceededMaxFileLimit` — this happens before `.warpindexingignore` is ever applied. 
So no matter what we put in that file, Warp hits its limit on the raw git-tracked file count (118,124) first.

The only way to fix this within the current architecture would be to get the git-tracked file count itself under 100,000 — which would mean adding patterns to `.gitignore`. 
That's pretty invasive and would affect git operations.

I don't know the exact date at which this changed, but I know that I was working successfully with the codebase at least back in December.

To reproduce

Presumably you could reproduce this with any large codebase that exceeds 100,000 files after .gitignore is applied by asking Warp to index the codebase and have it say Failed and/or Codebase too large when you go to sync.

If you want to reproduce my exact scenario, you could clone stdlib:

git clone --depth=1 https://github.com/stdlib-js/stdlib.git

Then cd stdlib and try and have Warp index the codebase with the included .gitignore and then try adding .warpindexingignore such as the one I've set up in the gist here, which should reduce the file count to < 100,000:
https://gist.github.com/batpigandme/ec13764ccaa83e00c410ee7d7b976590

If you go to settings > Code > initialized indexed folders stdlib will either say Failed or Codebase too large.

Expected behavior

I expect the codebase to indexing to succeed if I have the file count below 100,000 files and that I can filter the number of files by using .warpindexingignore.

Screenshots, videos, and logs

Here's the full agent conversation: https://app.warp.dev/conversation/b03c63ab-3205-4776-a5a7-8930c943bd37

Failing before I manually try to sync:

Codebase too large after manually trying to syn:

Operating system (OS)

macOS

Operating system and version

MacOS Tahoe 26.3.1

Shell Version

zsh 5.9 (arm64-apple-darwin25.0)

Current Warp version

v0.2026.03.04.08.20.stable_03

Regression

Yes, this bug started recently or with an X Warp version

Recent working Warp date

I don't actually know…maybe a month ago?

Additional context

You can see in the greyed-out bit of the convo that it reports that Warp builds a file tree for the filesystem THEN applies the ignore rules.

Most relevant part of agent convo

Unfortunately the docs don't expose a way to see Warp's exact file count. The Settings > Code UI only shows status states ("Synced", "Too large", etc.), not the raw number it evaluated.

The most productive path forward is probably to check Warp's local logs to see if it reports a count. Let me look:

Command Executed:

find ~/Library/Logs -name "*.log" -path "*warp*" 2>/dev/null | head -10

Output:

/Users/maraaverick/Library/Logs/warp.log

Command Executed:

grep -i "too large\|file count\|files found\|indexing\|stdlib\|100000\|limit" ~/Library/Logs/warp.log 2>/dev/null | tail -30

Output:

2026-03-19T15:19:26Z [INFO] Increased open file descriptor limit to 2560
2026-03-19T15:19:28Z [INFO] Discarding expired codebase index snapshot for "/Users/maraaverick/stdlib"
2026-03-19T15:19:28Z [INFO] Discarding expired codebase index snapshot for "/Users/maraaverick/stdlib/lib/node_modules/@stdlib/array"
2026-03-19T15:19:28Z [INFO] Discarding expired codebase index snapshot for "/Users/maraaverick/stdlib-icorps-notes"
2026-03-19T15:19:28Z [INFO] Reading snapshot from file for repo "/Users/maraaverick/stdlib/lib/node_modules/@stdlib/array"
2026-03-19T15:19:28Z [INFO] Merkle tree parsed from snapshot for repo "/Users/maraaverick/stdlib/lib/node_modules/@stdlib/array"
2026-03-19T15:19:28Z [INFO] Diffing filesystem with tree from snapshot for repo "/Users/maraaverick/stdlib/lib/node_modules/@stdlib/array"
2026-03-19T15:19:28Z [INFO] Reading snapshot from file for repo "/Users/maraaverick/stdlib"
2026-03-19T15:19:28Z [INFO] Merkle tree parsed from snapshot for repo "/Users/maraaverick/stdlib"
2026-03-19T15:19:28Z [INFO] Diffing filesystem with tree from snapshot for repo "/Users/maraaverick/stdlib"
2026-03-19T15:19:30Z [WARN] Failed to construct symbols outline for repo: Repo size exceeded max file limit
2026-03-19T15:19:30Z [INFO] Diffed filesystem with tree from snapshot for repo "/Users/maraaverick/stdlib/lib/node_modules/@stdlib/array"
2026-03-19T15:19:30Z [INFO] Syncing from snapshot for repo "/Users/maraaverick/stdlib/lib/node_modules/@stdlib/array"
2026-03-19T15:19:30Z [WARN] Failed to construct symbols outline for repo: Repo size exceeded max file limit
2026-03-19T15:19:30Z [INFO] Synced from snapshot for repo "/Users/maraaverick/stdlib/lib/node_modules/@stdlib/array"
2026-03-19T15:19:30Z [INFO] Reading snapshot from file for repo "/Users/maraaverick/stdlib-icorps-notes"
2026-03-19T15:19:30Z [INFO] Merkle tree parsed from snapshot for repo "/Users/maraaverick/stdlib-icorps-notes"
2026-03-19T15:19:30Z [INFO] Saving workspace metadata for "/Users/maraaverick/stdlib/lib/node_modules/@stdlib/array" to SQLite
2026-03-19T15:19:30Z [INFO] Diffing filesystem with tree from snapshot for repo "/Users/maraaverick/stdlib-icorps-notes"
2026-03-19T15:19:30Z [INFO] Diffed filesystem with tree from snapshot for repo "/Users/maraaverick/stdlib-icorps-notes"
2026-03-19T15:19:30Z [INFO] Syncing from snapshot for repo "/Users/maraaverick/stdlib-icorps-notes"
2026-03-19T15:19:31Z [INFO] Synced from snapshot for repo "/Users/maraaverick/stdlib-icorps-notes"
2026-03-19T15:19:38Z [WARN] Failed to build file tree for repository: ExceededMaxFileLimit
2026-03-19T15:19:40Z [ERROR] Failed to diff filesystem with tree from snapshot: DiffMerkleTreeError(ExceededMaxFileLimit)
2026-03-19T15:20:19Z [INFO] Retrying indexing for previously failed repository: /Users/maraaverick/stdlib
2026-03-19T15:20:19Z [INFO] Saving workspace metadata for "/Users/maraaverick/stdlib" to SQLite
2026-03-19T15:20:28Z [WARN] Failed to build file tree for repository: ExceededMaxFileLimit
2026-03-19T15:29:28Z [WARN] Unable to write snapshot: No Merkle tree available to serialize index at "/Users/maraaverick/stdlib"
2026-03-19T15:44:44Z [INFO] Retrying indexing for previously failed repository: /Users/maraaverick/stdlib
2026-03-19T15:44:44Z [INFO] Saving workspace metadata for "/Users/maraaverick/stdlib" to SQLite

The logs reveal the key issue. Warp is failing at the file tree building stage with ExceededMaxFileLimit — this happens before .warpindexingignore is ever applied. So no matter what we put in that file, Warp hits its limit on the raw git-tracked file count (118,124) first.

The only way to fix this within the current architecture would be to get the git-tracked file count itself under 100,000 — which would mean adding patterns to .gitignore. That's pretty invasive and would affect git operations.

---

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.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[batpigandme]

Additional info:

Tried to dig into this a bit more by looking at the codebase_index_snapshots, and got:

• snapshot_8689441230563533936 — the full /Users/maraaverick/stdlib root index (51M, last indexed Mar 9)

There's nothing in the changelog since March 9 (it just has an update for autodetecting Figma for the March 11 release) that seems related to the way the file tree is being processed, but it's possible I was running an older version of Warp at that point.

[kevinyang372]

Hey @batpigandme we are actively working on a fix for this!