Can you delete /private/var/folders on a Mac, and what is in it

2 October 2026 · 6 min read

No, not by hand. /private/var/folders is where macOS keeps each account’s temporary files and per-user caches, and apps and system services are using files in there the whole time you are logged in. Pulling the folder out from under them causes failed saves, crashes and odd resets, and the space comes back within days anyway.

macOS already cleans part of it on its own schedule, and a restart gives it the chance to. If one item in there is genuinely huge, deal with that item, not the folder.

What the folder is

/var is a link to /private/var, so the two paths are the same place. Inside folders you will find a few two-character folders, and inside each of those, one long random-looking folder per account. System services such as the window server get their own folders here too, so it is not only yours.

You do not have to guess which one is yours. Ask macOS in Terminal:

getconf DARWIN_USER_TEMP_DIR
getconf DARWIN_USER_CACHE_DIR

Each prints a path like /var/folders/7k/q2m9x4r81b5_hd03lz8wkpt80000gn/T/, the first ending in T and the second in C. The $TMPDIR variable in Terminal points at the same T folder. Apple documents these locations on the confstr manual page (man confstr), and the details there are the useful part:

T is temporary items. Apps write here while they work: half-finished exports, files being unpacked, lock files, and the scratch copies some apps make while saving a document. The manual says files here may be removed by the system if they have not been accessed in three days.

C is caches. Per-user caches for system services and apps: the font cache in com.apple.FontRegistry, Quick Look thumbnails under com.apple.quicklook.ThumbnailsAgent, and a folder for most apps you run. The manual says this location is not cleaned automatically, and that its files are removed during a safe boot.

0 is a per-user folder (getconf DARWIN_USER_DIR) where system services keep small amounts of state. The Launchpad layout database lives here, in com.apple.dock.launchpad.

X is not described on that page. On a Mac we checked, it held only folders ending in code_sign_clone, which some browsers appear to create as a cloned copy of their own app while they run. Apple does not document this folder, so treat it as off limits.

Why deleting it by hand goes wrong

Files are open. A running app that loses its temporary folder mid-task fails in whatever way its developer least expected: an export that dies near the end, a save that reports it could not complete, a crash on the next write. Many Mac apps save a document by writing a new copy in a temporary location and swapping it in, and those copies often sit in T/TemporaryItems.

Lock files go missing. Some tools leave a small lock file in T to stop two copies of a job running at once. Delete it while the job runs and the protection is gone.

State resets. Remove 0 and things like the Launchpad arrangement go back to the default, which you then rebuild by hand. Not a disaster, and not what you were trying to do.

Permissions get mangled. These folders are created with specific owners and permissions. macOS recreates any that are missing when they are next requested, but a folder recreated by hand, or a sudo rm -rf across every account, can leave the wrong owner behind, and apps then cannot write where they expect to.

The space returns. Caches regenerate and temporary files are temporary. The internet advice to empty this folder trades a slower, flakier day for a few gigabytes that soon refill. Which caches are safe to delete on a Mac covers the same trade for your Library folder.

What a restart actually clears

macOS runs a cleanup helper called dirhelper from /System/Library/LaunchDaemons/com.apple.bsd.dirhelper.plist. Read that file (plutil -p prints it): on recent versions of macOS it is set to run at startup and again every day at 3:35 a.m., with a setting to clean files older than three days. So:

• A restart lets that cleanup run, and quitting every app on the way down gives the ones that tidy up after themselves the chance to. Recent temporary files survive, which is correct: something may still need them.
• If the Mac is asleep at 3:35, launchd runs the job when it next wakes (the launchd.plist manual page says so), so a Mac that is never restarted still gets the daily pass.
• The caches in C are left alone by both. To clear them the supported way, start up in safe mode once. On Apple silicon, shut down, press and hold the power button until the startup options appear, select your startup disk, then hold Shift and click Continue in Safe Mode. On an Intel Mac, restart and hold Shift until the login window appears. Then restart normally. The first startup afterwards can be slower while fonts and thumbnails rebuild.

Apple documents the three-day rule. It does not document exactly what happens to each subfolder at startup, so treat a restart as housekeeping, not a guaranteed wipe.

Measure your own share before deciding anything

These commands read only your own folders and need no administrator password:

du -sh "$(getconf DARWIN_USER_TEMP_DIR)" 2>/dev/null
du -sh "$(getconf DARWIN_USER_CACHE_DIR)" 2>/dev/null
du -h -d 1 "$TMPDIR" 2>/dev/null | sort -h | tail -10

The first two give totals. The third lists the largest folders inside T, biggest last. The 2>/dev/null hides the “Operation not permitted” and “Permission denied” lines that are normal here: macOS and some apps protect a few items even from their owner, so the totals leave those out.

A few gigabytes across T and C is ordinary. Tens of gigabytes usually means one specific thing, and the folder name tells you what: most are named after the app that made them, either in plain words or as a reversed web address such as com.apple.FontRegistry. If you find one:

1. Quit the app it belongs to.
2. Move that one folder to the Trash, not the whole parent.
3. Restart, use the Mac for a day, then empty the Trash.

One caveat about the numbers. du counts APFS clones at full size even when they share space on the disk, so a folder of cloned copies, like the code_sign_clone folders above, can look far larger than what it really costs. Quit the browser before touching them.

How this fits into System Data

Storage settings does not list /private/var/folders anywhere by name; it is generally counted in the System Data figure in System Settings, General, Storage, alongside logs, snapshots and app data. If System Data is your real complaint, this folder is one suspect among several, and often not the biggest. What System Data is on a Mac goes through the others in order.

That is also where Crumb helps. Its read-only audit breaks System Data into caches, logs, swap, temporary files and leftovers, so you can see whether temporary files are even the problem before you open Terminal. If something looks wrong, Ask Crumb (part of the $9 one-time unlock) explains what an item is, whether it regenerates and what breaks if it is gone, then proposes a plan. Nothing is deleted until you approve it, which is exactly the step a hand deletion of this folder skips.

Questions

Is /private/var/folders a sign of malware? No. Every Mac has it. macOS generates the random-looking names itself, one per account, and creates the T and C folders so that only their owner can read them.

I already deleted it. What now? Restart straight away. macOS recreates the folders it needs as they are requested. Expect slower first launches while caches rebuild and a reset Launchpad layout, and if an app misbehaves afterwards, quitting and reopening it usually lets it recreate what it lost.

Does it hold anything I would miss? Rarely anything you made yourself, with one exception: an app that crashed during an export or a save may have left the only partial copy in T. If you lost work that way, look there before it reaches three days old.