If you scan the same handful of large project folders repeatedly, a meaningful chunk of every scan's time goes into walking directories you already know you don't need counted — a node_modules tree with tens of thousands of small files, or a .git history you're not trying to audit. VolumeLens's exclusion patterns exist for exactly this case: tell it once what to skip, and it stops descending into that subtree entirely on every scan after, rather than walking in and discarding the result.

What an exclusion rule actually does

An exclusion in VolumeLens isn't a filter applied after the fact — it changes what the scan engine does while it's walking the disk. When an entry matches a rule, VolumeLens records it with an excluded flag, reports its size as zero, and does not descend into it. If it's a folder, none of its contents are walked at all. That last part is what makes exclusions a genuine speed improvement rather than just a display preference: a node_modules folder with fifty thousand files costs real time to enumerate, and skipping the descent avoids that cost entirely rather than paying it and hiding the result afterward.

Excluded items are never silently dropped from the view, though. They still appear in the treemap, marked with an eye-slash icon and labelled as excluded by your rules, so you're never wondering whether a folder was scanned and found empty, or simply skipped. That distinction matters — a storage tool that hides what it didn't look at is a tool you can't fully trust, and it's why VolumeLens shows exclusions rather than quietly omitting them from the map.

The three kinds of pattern

VolumeLens supports three ways to match an entry for exclusion:

  • Name glob — matches the entry's own name using standard glob syntax, so node_modules matches any folder with that exact name anywhere in the scan, and *.tmp matches any file ending in .tmp regardless of location.
  • Path prefix — matches when an entry's path, relative to wherever you started the scan, begins with a specific prefix, useful for excluding a specific subtree rather than every folder sharing a name.
  • Kind — matches by file kind rather than name, for cases where you want to exclude a category (symlinks, for instance) rather than anything matching a particular name pattern.

Most developers only need name globs. pathPrefix and kind rules are there for the less common cases where a name-based rule would be too broad or too narrow for what you're trying to skip.

Common patterns worth setting up

Pattern Type What it skips
node_modules Name glob Every JavaScript dependency tree, regardless of project
.git Name glob Git's internal history and object store
DerivedData Name glob Xcode's build output folder
*.tmp Name glob Temporary files by extension, wherever they appear
Pods Name glob CocoaPods dependency checkouts

These five cover most of what a developer's Mac generates repeatedly and rarely needs re-scanning byte-for-byte — you already know roughly how big a node_modules folder is going to be, and re-walking it on every scan of a parent project folder mostly costs time without adding new information.

Setting up a rule

Rules can be added two ways. The first is directly in Settings → Scanning, where a text field takes a name pattern — the interface itself gives the same examples above, node_modules or *.tmp, as a starting point. The second is contextual: right-click any folder in the treemap after a scan and choose to exclude it from future scans, which adds a rule based on that folder's name without needing to type it manually. Either way, a new rule applies starting with your next scan — it doesn't retroactively change results already on screen, since the whole point is changing what the scanner does while it walks, not filtering results after the fact.

Why this matters more as project count grows

The time saved by a single exclusion rule on a small project is negligible. The case where it matters is scanning a parent folder containing many projects — a ~/Code or ~/Projects directory with a few dozen repositories, each with its own node_modules, .git, and possibly DerivedData if any are Xcode projects. Without exclusions, a scan of that parent folder walks every one of those subtrees in full. With node_modules and .git excluded, the scan covers the same folder structure but skips the bulk of what would otherwise be the majority of files touched, since dependency trees and git object stores are typically far larger in file count than a project's actual source.

What exclusions are not

It's worth being precise about what this feature does and doesn't do, since it's easy to conflate with related ideas. It is not an incremental or differential scan — VolumeLens walks the full disk (or scope) you point it at every time; exclusions reduce what that full walk has to touch, but they don't create a cached "what changed since last time" scan. And excluding a folder from scanning is not the same as excluding it from cleanup consideration in some separate sense — an excluded folder is excluded from the count and the map entirely, which is why it's worth being deliberate about what you add a rule for, rather than excluding anything you'd occasionally still want visibility into.

Where this fits into the bigger picture

Exclusion patterns are a small feature with an outsized effect on repeat scans of a developer-heavy folder structure. VolumeLens is built to make repeated scanning practical rather than something you do once and avoid afterward, and rules like these are part of that — set them up once for the handful of folder names you already know you don't need re-counted, and every scan afterward gets faster and more focused on what's actually worth reviewing.