Reproduction steps

1. Start Zed on macOS from a normal install.
2. Open the affected workspace.
3. Leave the workspace open while background indexing/scanning runs.
4. Wait for ongoing worktree/FSEvents activity.
5. Observe Zed's memory usage continue climbing instead of plateauing.
6. Capture sample / vmmap while memory is high.

Current vs. Expected behavior

Current behavior:

Zed can grow to an extreme heap footprint while indexing the workspace and become effectively unusable under memory pressure.

In my captures:

• Zed reached a 61.9G physical footprint.
• The later vmmap still showed heap growth rather than recovery.
• MALLOC_SMALL was 61.5G.
• The default malloc zone was 60.7G allocated.
• IOSurface was only 38.6M.
• IOAccelerator (graphics) was only 19.3M.

This looks like heap/object growth in the worktree/background scanning path, not a GPU/IOSurface leak.

The hot stacks in the samples are in:

• LocalWorktree::start_background_scanners
• BackgroundScanner::scan_dirs
• BackgroundScanner::scan_dir
• Snapshot::absolutize
• RelPathComponents::next
• fs_watcher::Watcher::add
• SumTree<worktree::Entry>::edit

The main thread was mostly idle in the normal AppKit event loop while this happened.

Expected behavior:

Background scanning/indexing should plateau at a reasonable memory footprint and release intermediate state as scanning progresses instead of retaining tens of gigabytes of heap.

Zed version and system specs

Zed: v0.227.1 (20260311.150302)
OS: macOS 26.3.1 (25D2128)
Memory 64 GB
Apple Silicon M4

Attach Zed log file

20260316-015932-ps.txt
20260316-020009-ps.txt
20260316-020009-vmmap-summary.txt
20260316-015932-vmmap-summary.txt

Relevant Zed settings

Relevant Keymap

No response

(for AI issues) Model provider details

No response

If you are using WSL on Windows, what flavor of Linux are you using?

None