deleted: the daemon behind your Mac's purgeable space

By CoreGuard · Aug 13, 2026 · 11 min read

What is the deleted process on a Mac?

deleted is macOS's purgeable-space daemon. Its man page — still shipping on macOS 26 with a footer date of September 10, 2013 — says it precisely: "deleted is a system daemon that keeps track of purgeable space via registered services. deleted listens for low-space events from the file system and attempts to avoid running out of disk space by requesting that clients purge space. deleted is not intended to be invoked directly."

In other words: when your disk runs low, this is the process that goes around asking other parts of macOS to give space back. It is the working half of the system Apple describes in the Disk Utility guide — purgeable space is "space that macOS can free up when needed by removing files from your computer (you can't manually remove the files that are designated purgeable, but macOS removes them as space is required)". The coordinator is deleted; the registered clients do the removing.

First, the name collision: which "deleted" are you looking at?

The top-ranking dedicated page for "deleted process on Mac" (MacKeeper's, dated June 2025) defines it as a file "removed or deleted while the process is still running" — leftovers of bad uninstalls — and prescribes cache-clearing and reinstalling macOS. That describes a real but different phenomenon: a running process whose binary was unlinked. The process literally named deleted in Activity Monitor is not that. It is Apple's purgeable-space daemon, signed com.apple.deleted and shipping inside the CacheDelete framework — its documentation dated 2013. If you searched because Activity Monitor shows deleted, this article is about your process.

Three names, one subsystem

The naming is genuinely confusing, so here is the map, verified on this Mac:

• deleted — the per-user agent. Binary at /System/Library/PrivateFrameworks/CacheDelete.framework/deleted; its launchd job is labeled com.apple.cache_delete (not "deleted"), ProcessType Adaptive, with EnablePressuredExit.
• deleted_helper — the root-side daemon (com.apple.deleted_helper), for the work that needs system privileges.
• CacheDelete — the private framework and subsystem name both of them serve. You'll meet it in logs as CACHE_DELETE_… fields and in crash-lore as "CacheDelete".

Both processes were running here mid-session: deleted at 8.7 MB and deleted_helper at 3.9 MB, each at 0.0% CPU — one moment on one Mac, a reference point rather than a norm.

The registry: 27 services that know how to purge

The man page's FILES section points at /System/Library/CacheDelete — "CacheDelete service definitions provided by Apple" — and you can list it yourself. On this macOS 26.6 Mac it holds 27 property lists, one per service that has volunteered space it can give back. The roster is a who's-who of the daemons this blog has covered: photolibraryd, MobileAsset, FileProvider, cloudd (twice — user and system), corespotlightd and mds from the Spotlight family, logd, installd, appstoreagent, Time Machine's cache service, Quick Look thumbnails, sysdiagnose and more.

The definitions vary in shape — some declare service lists, others only notification hooks or just an identifier. A representative one that does declare services reads:

$ plutil -p /System/Library/CacheDelete/com.apple.AssetCache.builtin.CacheDelete.plist
  "CACHE_DELETE_ID" => "com.apple.AssetCache.builtin.CacheDelete"
  "CACHE_DELETE_SERVICES" => [ "PURGE", "PERIODIC" ]

In this one, PURGE means "I can free space when asked" and PERIODIC means "I also do scheduled cleanup" — other definitions (Time Machine's, FileProvider's, photolibraryd's among them) wire themselves up differently. The count is version-dependent — Howard Oakley counted 32 definitions on Ventura 13.3.1; this Mac's 26.6 install has 27 — so treat the roster as a snapshot, not a constant. The idea is the durable part: cache deletion on macOS is a registry of owners, not a folder to empty. deleted doesn't reach into caches; it asks the process that owns them.

How the purge actually runs

Oakley's Ventura-era log analysis (April 2023) established the choreography, and his 2026 work shows the same subsystem active through macOS 26: purging proceeds in escalating rounds — volume caches first, then subsystem caches like Quick Look thumbnails and Mail's, then registered services' caches, and Time Machine snapshots last — with urgency levels, and it stops as soon as enough space is freed. During a macOS Tahoe update, he traced com.apple.cache_delete running repeated purge rounds through the whole preparation.

Two more of his findings explain everyday weirdness better than any cleaning tip. The free-space figures in Disk Utility come from this subsystem — "apps like Disk Utility get their figures for free space on volumes…from the space management feature in macOS, its CacheDelete subsystem" — while a Finder Get Info window can show stale numbers precisely because "no call is made to CacheDelete" when it opens. If Finder and Disk Utility disagree about your free space, you're not going mad; you're seeing who asked the subsystem and who didn't. (The Storage panel itself, per his December 2025 explainer, "has become more reliable" in Tahoe 26.2 after years of being "notorious for its fragility and inaccuracy".)

And the subsystem has teeth. In an April 2025 Apple developer-forums thread, CacheDelete was terminating sandboxed apps to reclaim their container caches when a disk fell to typically around 10% free (the thread notes it occasionally struck with more space than that) — and Apple's own engineer confirmed the behavior, advising developers that "avoiding the termination itself is the wrong way to approach this issue" and to make their helpers relaunchable instead. Low disk space is a condition macOS takes seriously enough to kill for.

Why this makes most cache-cleaning pointless

Here is the honest chain. Purgeable space is, by Apple's definition, space macOS frees itself when needed. The freeing is done by a dedicated daemon, working from a registry of cache owners, in a careful order, stopping when it has enough. So what does manually deleting caches buy you? Oakley tested exactly that in September 2023 and concluded: "At most, it's only likely to free purgeable space. At worst, it may not free any significant storage space." You spend the cache's benefit — apps rebuild what they need — without gaining space you couldn't have had on demand.

There's a sharper irony in the record. The two documented cases of the deleted process itself showing sustained CPU were both caused by utilities watching or "protecting" the disk: a 2023 MacRumors thread traced sustained 10–50% CPU to CleanMyMac X's background protection features (the owner resolved it by turning those features off — "It's Cleanmymac X triggering 'deleted' in the background all the time!"), and back in 2016, iStat Menus 5.20's disk monitoring hammered cache_delete until the vendor shipped a fix in build 687. Both are dated, specific, third-party bugs — not an indictment of those apps today — but the pattern is worth naming: the space subsystem mostly makes news when something outside it won't stop poking it.

"Purgeable space isn't clearing" — the honest causes

The complaint behind most searches for this daemon is a purgeable number that won't go down, or free space that vanished. The documented causes, notably, are not the caches people usually blame:

• Time Machine local snapshots — the best-documented holder in the record, and deliberately the last thing purged. Forum cases from 2025–2026 include corrupted com.apple.asr snapshots holding about 400 GB (leaving the poster almost 500 GB free once thinned) — and, months later for the same user, a display that showed nearly a terabyte free after another purge while Disk Utility and OmniDiskSweeper both measured about 470 GB: the display, not the disk, was wrong. A pending macOS update also keeps a snapshot around that grows until you install or delete the update.
• Space held for reasons that aren't purgeable — evicted iCloud files and snapshots are often assumed purgeable when they aren't counted that way, per Oakley's purgeable-space explainer.
• Stale displays — a Finder window that never asked CacheDelete (above). Measure in Disk Utility, which does.

What the record does not support: sudo purge (it flushes the filesystem's memory cache, not purgeable storage), filling the disk with dd to force a purge (one vendor page recommends this while itself noting the trick "no longer works with APFS" — and a botched fill on a boot volume is its own emergency), or treating a vendor's "purgeable can reach 80% of your disk by design" line as fact (it traces to one app's uncited marketing page). If snapshots are the cause, tmutil thinlocalsnapshots and Disk Utility's snapshot view are the documented levers; if nothing is actually short of space, the honest move is to let the daemon do its job when the space is genuinely needed.

When deleted deserves attention

Same reading as every daemon here: shape plus symptom. Momentary activity around low-space moments is the design working. Sustained CPU from deleted across days is unusual — and in both documented cases the cause was another utility polling the subsystem, so the productive question is "what keeps asking for space evaluations?", not "how do I kill deleted?" (launchd relaunches it, and the low-space condition that woke it is still there). A disk that is genuinely full is the other honest trigger — that's a storage problem, not a daemon problem, and the System Data explainer covers where the space actually goes.

How to read your Mac's purge subsystem

1. Confirm which "deleted" you have. In Activity Monitor (View → All Processes), the purgeable-space daemon appears as deleted, and deleted_helper may accompany it. Sample it (Activity Monitor's Sample Process) and the header shows its path inside CacheDelete.framework, with com.apple.CacheDelete among the loaded frameworks — an idle daemon's stack itself just shows it waiting.
2. List the registry. ls /System/Library/CacheDelete/ shows every Apple service registered with the purge subsystem on your macOS version — read-only, no sudo.
3. Measure space where the subsystem answers. Use Disk Utility for free/purgeable figures; treat a disagreeing Finder Get Info window as stale rather than as a second opinion.
4. If purgeable won't clear, check snapshots first. Disk Utility's snapshot view (or tmutil listlocalsnapshots /) shows what's held; thinning snapshots is the documented lever — in the documented cases the story was snapshots, not caches.

Where CoreGuard fits

CoreGuard is an honest, local-only Mac health monitor — it observes and explains, and never cleans or optimizes. That stance is not ideology; it's this article's mechanism taken seriously: macOS already employs a daemon whose whole job is freeing space at the right moment, so CoreGuard's role is the part macOS doesn't show you — live readings with the top process named in plain English, and a per-minute history of system CPU, memory and temperature, so "deleted has been busy for three days" is a visible shape instead of a hunch. It makes no network connections of any kind, and the danger-visibility layer is free, always.

Frequently asked questions