Project Explorer fails to expand populated folders in large repos after ExceededMaxFileLimit

[danielflorezjllo]

Summary

Project Explorer can show dot-directories (for example .agents) as non-expandable/empty in large repositories because file tree construction fails with ExceededMaxFileLimit.

Problem

In workspace root ~/code, the .agents folder is visible in Warp's sidebar but appears empty or does not expand as expected, even though it contains many files and subdirectories on disk.

Expected behavior

Project Explorer should either (a) expand .agents and show its contents, or (b) show a clear, user-visible message that indexing/tree generation was limited due to repository size.

Actual behavior

The folder appears effectively empty/non-expandable in the sidebar while filesystem checks confirm it is populated. Logs show file tree generation failures:

• Failed to build file tree for repository: ExceededMaxFileLimit
• repo root: ~/code

Reproduction steps or desired workflow

1. Open Warp with project root ~/code.
2. In Project Explorer, try to expand .agents.
3. Observe it appears empty or does not show expected contents.
4. Check local filesystem and logs:
   • .agents contains many files/subfolders.
   • ~/Library/Logs/warp.log includes repeated Failed to build file tree for repository: ExceededMaxFileLimit events for this repo root.

Artifacts

• Log evidence from ~/Library/Logs/warp.log:
  • Failed to build file tree for repository: ExceededMaxFileLimit
  • repeated occurrences tied to ~/code
• Local repository scale at time of investigation: ~153,428 tracked files.

Warp version

Latest

Operating system

macOS (version unknown)

[oz-for-oss]

@danielflorezjllo

Here's what I found while triaging this issue:

• This appears tied to Warp's large-workspace file-tree size guard rather than .agents specifically.
• The provided logs and repository scale are enough to route this as a reproducible Project Explorer bug.

Maintainer details

I concluded that project Explorer likely renders populated folders as empty in very large local repos when the repo metadata file-tree build hits Warp's file-count guard and the failed state is not surfaced persistently in the sidebar..

Triage

This looks like a Project Explorer bug in the local repository metadata/file-tree path for very large workspaces. The reported repository size (~153k tracked files) exceeds the current full-repo file-tree quota, and the reported log line matches the failure emitted when repository tree construction returns ExceededMaxFileLimit.

Reproducibility

High. The report includes a concrete workflow, filesystem verification that .agents is populated, and repeated logs tied to the affected repository root. A local repro should use a workspace with more than 100k non-ignored files and then open Project Explorer on that root.

Likely root cause

LocalRepoMetadataModel::index_directory builds the full repository tree with a MAX_FILES_PER_REPO quota of 100,000. When Entry::build_tree exceeds that quota it returns BuildTreeError::ExceededMaxFileLimit, the repository is marked Failed, and RepoMetadataModel::get_repository returns no usable tree for the Project Explorer. FileTreeView handles UpdatingRepositoryFailed by refreshing the displayed directory contents, but the failed repo state is not rendered as a persistent, user-visible explanation; this can leave folders shown with empty/lazy contents or only an ephemeral toast on later lazy-load failures.

Duplicate check

I scanned all open issues and recent closed issues. #8911 is closely related because it also hits ExceededMaxFileLimit during large-codebase file-tree construction, but I found fewer than two likely duplicate issues, so I am not marking this issue as a duplicate.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz