Can I Delete the var/folders Directory on Mac? What That Huge Folder Actually Is

You ran du -sh /* or opened a disk-space analyzer, and suddenly /private/var/folders is staring back at you with several gigabytes claimed. The name is cryptic, the path is hidden, and every instinct says to delete it. This guide explains exactly what lives inside that directory, why it bloats, and the right way to reclaim the space without breaking your Mac.

What Is /private/var/folders on Mac?

/private/var/folders is macOS's per-user temporary directory tree. When you type /var/folders in Terminal, you are actually looking at a symlink that resolves to /private/var/folders. The two paths point to the same place.

Apple introduced this layout to give every user account a private scratch space that is separate from global system directories. The structure looks like this:

/private/var/folders/
  zz/
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
      T/    ← per-session temp files
      C/    ← per-user caches
      0/    ← app-specific persistent data

The two-letter subdirectory (zz, qr, mn, etc.) and the long random string beneath it are generated once per user account and stay stable across reboots. This is intentional: apps store references to these paths and expect them to remain consistent during a login session.

The three subfolders have distinct roles:

• T/ (Temporary Items): Short-lived scratch files. In theory macOS clears these at logout or reboot, but in practice many files accumulate here over weeks.
• C/ (Caches): User-scoped cache files that parallel what you find in ~/Library/Caches. These are regenerated on demand.
• 0/ (Application Support-like data): Persistent per-user data that apps place outside the normal Library hierarchy. Some apps write large files here.

Why Does private/var/folders Get So Large?

Several culprits drive the size of this directory on a typical Mac in 2025 and 2026:

Xcode and Developer Tools

Xcode's build system, Swift Package Manager, and clangd all deposit sizeable caches under /private/var/folders. A single large project can push hundreds of megabytes into the C/ subtree. If you have run Xcode simulators, compiled frameworks, or used xcodebuild in CI scripts, this is likely the biggest contributor.

App Caches That Bypass ~/Library/Caches

Some apps, especially those sandboxed on older SDK targets, write cache data into /private/var/folders rather than the standard ~/Library/Caches path. Browsers, media apps, and virtualization tools (Parallels, VMware) are frequent offenders.

Stale Temp Files From Crashed Processes

When an app crashes or is force-quit, it often leaves files in the T/ subtree that were never cleaned up. Over months of normal use these accumulate. A common example is large partially-written downloads or export files left by video and audio editors.

macOS Itself

Spotlight indexing metadata, Quick Look thumbnail caches, and certain CoreData journal files all touch /private/var/folders. These are typically small, but on high-activity machines they add up.

Can I Delete var/folders on Mac? The Direct Answer

The short answer: do not delete the directory itself or its top-level structure. Running sudo rm -rf /private/var/folders will cause immediate and serious problems. macOS creates the user folder node at login and caches the path in the kernel's security layer (Sandbox), in launchd, and inside running app processes. Removing it mid-session can crash apps, corrupt preferences, and in extreme cases force a reboot with a partially broken user environment that requires a re-login or even a profile repair.

What you can safely do is clear the contents of the T/ (temporary) and C/ (cache) subtrees, provided you do it correctly:

1. Close or quit apps before clearing their cache files. An app actively writing to a cache file it has open will either corrupt the file or immediately recreate it.
2. Never delete the parent folder nodes themselves, only the files and subdirectories inside T/ and C/.
3. Do not touch the 0/ subtree unless you know exactly what is in there. Some apps store data here that is not easily regenerated.

How to Find Your Specific Folder Path

Your user-specific node has a randomized name. To find it, run this in Terminal:

getconf DARWIN_USER_TEMP_DIR

That prints something like /var/folders/zz/xxxxxx/T/. The parent of T/ is your user node. You can also use:

getconf DARWIN_USER_CACHE_DIR

to get the C/ path directly.

The Safe Manual Way to Clear Temp Files in Terminal

Once you have your path, you can remove the contents of the temp folder like this (replace the path with your actual output from the command above):

# Clear temporary items only, do NOT remove the T/ folder itself
rm -rf /var/folders/zz/xxxxxx/T/*

Some files will refuse deletion with a "Resource busy" error. That is expected. Those are files currently held open by running processes. Leave them alone. The rest will be cleared.

For the cache folder:

rm -rf /var/folders/zz/xxxxxx/C/*

Again, locked files will be skipped. That is correct behavior, not a failure.

What About the Xcode Caches Specifically?

If Xcode-related entries are eating the most space, you have more targeted options:

# DerivedData (build artifacts)
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# Xcode caches in var/folders (safe after quitting Xcode)
xcrun simctl delete unavailable

The xcrun simctl delete unavailable command removes simulator runtimes you no longer need. These are stored elsewhere but contribute to overall developer bloat. After running these, the /private/var/folders caches that Xcode regenerated for those simulators will also be stale and safe to remove.

Why Automated Tools Are Safer Than Manual rm Commands

The manual approach works, but it has real risks:

• You might accidentally remove the parent folder node, not just its contents.
• A glob like T/* does not follow symlinks safely in all shell configurations.
• You have no visibility into which files belong to which app, making it hard to decide what is truly stale versus actively used.

A tool that understands the macOS cache hierarchy can enumerate files by age, owning process, and app bundle, show you a reviewable list before deleting anything, and skip files that are currently open. That is a different risk profile than a raw rm -rf.

Crumb, for example, scans your /private/var/folders temp and cache contents as part of its system cache sweep, shows you what it found grouped by app, and runs an "is this safe to delete?" check before touching anything. Everything stays on-device and no account is needed. It will not delete the folder structure itself, only stale contents that are genuinely safe to remove.

Will Deleting These Files Break Anything?

For T/ contents: almost never. macOS designed these as truly temporary. Apps recreate what they need on next launch.

For C/ contents: you may see a one-time slowdown after clearing, because apps regenerate caches on demand. Xcode's first build after clearing its cache folder will be slower than usual. A web browser may re-render pages more slowly for a session. These are cosmetic, not structural problems.

For 0/ contents: treat with caution. Some apps store state here that does not regenerate cleanly. Unless you know what a specific subdirectory contains, leave it alone.

Quick Summary: What to Do

• Do not delete /private/var/folders or any of its parent nodes.
• Do not run sudo rm -rf on the whole directory.
• Safe to clear: contents of your user T/ (temp) and C/ (cache) folders.
• Use getconf DARWIN_USER_TEMP_DIR to find your exact path before doing anything.
• Close apps first, accept "Resource busy" errors on locked files, and never remove the folder nodes themselves.

The /private/var/folders directory is one of the more misunderstood corners of macOS storage. It bloats gradually and invisibly, and the cryptic path makes it feel like a prime candidate for a blunt delete. Knowing what actually lives there makes it possible to clear the waste safely and confidently, without risking a broken login session. If you would rather not do the path-hunting manually, Crumb handles the sweep automatically and shows you exactly what it plans to remove before anything is touched.