Time Machine CacheDelete reports 0 bytes purgeable on macOS Tahoe 26.6.2 (August 27, 2026)
Chapters
What is new since August 24
On August 24 the symptom was documented and the cause was not. The Finder refused a 12.89 GB copy onto a volume whose space was in fact purgeable, and the position then was plain: 'Time Machine snapshots are purgeable, although they may not always be purged reliably. The cause of that unreliability is unknown.' That was The Eclectic Light Company on August 24, 2026, which I covered in the August 24 post.
What August 27, 2026 adds is the failing component and two timings. The component is Time Machine's own CacheDelete provider. The timings show that even when the mechanism eventually works, it can take half an hour, and that two volumes set up the same way do not behave the same way.
TL;DR
The macOS Tahoe 26.6.2 failure that refuses a large file copy now has a named component: Time Machine's CacheDelete provider told the system that 0 bytes were purgeable when about 94.9 GB were, according to The Eclectic Light Company on August 27, 2026. That answer comes from the deleted daemon's poll of every registered cache service, so a wrong answer from one provider is enough to block the write. Apple has not acknowledged it and there is no fix as of August 27, 2026, which leaves deleting snapshots by hand as the only reliable way to get the space back.
- Log analysis showed 'Time Machine CacheDelete returning 0 bytes instead of the 94.9 GB that should have been purgeable'.
- The polling is done by the deleted service through the subsystem com.apple.cache_delete, before the write is allowed.
- Two identically configured test volumes with over 90 GB purgeable behaved differently: one disclosed the space 24 minutes after deletion, the other had disclosed none after 36 minutes.
- The published workaround is verbatim: 'If you need to free up space in a container, don't rely on the automatic purging of snapshots. Delete them yourself in Disk Utility.'
- Deleting snapshots destroys your recent local restore points, and macOS Tahoe 26.7 was still at release candidate 2 with nothing about this in it.
How the refusal actually happens
Before macOS allows a large write onto a nearly full volume, the deleted service asks each registered cache service how much space it could release. That poll runs through the subsystem com.apple.cache_delete, and Time Machine's local snapshots are one of the caches that answer it.
In the logs, Time Machine CacheDelete answered 0 bytes when roughly 94.9 GB should have been reported. From the system's point of view there is nothing to reclaim, so the copy is refused and the Finder reports that there is not enough space. The volume is not full and your data is not too big. One provider gave the wrong number and everything downstream believed it.
Even when it works, it is slow and it is not deterministic
The follow-up tests used two volumes configured identically, each with over 90 GB of purgeable space. One took almost 30 minutes to make that space available, which is 24 minutes after the files were deleted. The other still had not disclosed any purgeable space after 36 minutes had elapsed.
That matters for how you diagnose this. A person who deletes files, waits a couple of minutes and finds the space missing cannot tell from the outside whether they are in the slow case or the broken case. Identical setups producing different results is also why this is worth calling out as a defect rather than as a documented delay.
| Test volume | Purgeable space | When it became available |
|---|---|---|
| Volume 1 | Over 90 GB | 24 minutes after file deletion |
| Volume 2 | Over 90 GB | None disclosed after 36 minutes |
| Reported by Time Machine CacheDelete | 0 bytes | Against about 94.9 GB actually purgeable |
Still no fix, and the workaround has a real cost
The recommendation is direct: 'If you need to free up space in a container, don't rely on the automatic purging of snapshots. Delete them yourself in Disk Utility.' Alongside it, check periodically for orphaned Time Machine snapshots that persist beyond 24 hours, since those are holding space nothing is going to reclaim for you.
The cost is your restore points. Deleting local snapshots is deleting the thing that lets you roll a volume back to this morning, so the price of the space is recent recoverability. It is also manual, it has to be repeated, and it assumes you know that local snapshots exist at all. Apple has not acknowledged the failure, and macOS Tahoe 26.7 was at release candidate 2, build 25G224, according to The Mac Observer on August 24, 2026, with nothing in it about purgeable space.
What you can do today
1. When a copy is refused for space, open Disk Utility and read the container's purgeable figure. The Finder and Storage settings omit purgeable space, so they cannot tell you whether this is what you are hitting.
2. Wait about half an hour before concluding the space is gone. One of the two test volumes took 24 minutes to disclose it, so an immediate retry proves nothing.
3. If you need the space now, delete the snapshots yourself in Disk Utility rather than waiting for automatic purging. Do it knowing you are giving up your recent local restore points.
4. Look for snapshots older than 24 hours while you are in there. Orphaned snapshots hold space that nothing is going to reclaim on its own.
5. Do not plan around the next update. On August 27, 2026 there was no Apple acknowledgement and no release that mentions this, so the manual routine is the only thing that works.
If repeating that check on every Mac you own is not how you want to spend the week, the honest answer is to have something else do it. Get XLAnt.
Frequently asked questions
Does this only affect macOS Tahoe 26.6.2?
26.6.2 is the version the testing was done on, and the failure is reported on any Mac with APFS volumes carrying Time Machine local snapshots. No Mac model restriction is reported. Because two identical volumes behaved differently, an affected Mac will not fail every time.
Is deleting snapshots safe?
It frees the space and it loses the rollback. Local snapshots are the local restore points, so deleting them in Disk Utility means you can no longer roll that volume back to the point the snapshot was taken.