macOS Tahoe 26.6.2 gives three different answers for used disk space (August 21, 2026)

The numbers that do not add up

The measurement was taken on macOS 26.6.2 against an internal SSD whose Macintosh HD container is roughly 1.995 TB. The same disk also carries an iSCPreboot volume of about 524 MB and a Recovery volume of about 5.4 GB.

Asked the same question about the same volume, macOS gives several answers. In the tested case, in the author's words, "the Finder's Get Info dialog for the Macintosh HD volume reports only 826.67 GB as used and Disk Utility claims even less at 814.03 GB". Meanwhile diskutil showed 1.158 TB free in the container, and the sum of volume usage, 837.027 GB, did not reconcile with the container figures. None of these are rounding differences.

Purgeable space is the hole in the middle

Purgeable space is space that macOS counts as available on the grounds that it can reclaim it when something needs the room. It is also, in the author's phrase, "a murky area" as to what triggers purging and what actually gets removed. There is no published rule, which means there is no way for you to predict the number or to force it.

Clone files, sparse files, compressed files and dataless files distort the arithmetic further, because the space a file appears to occupy and the space it costs the container are not the same quantity on APFS. That is the honest reason the tools disagree: they are answering slightly different questions, and macOS does not tell you which question each one answered.

Not acknowledged, not fixed

As of August 21, 2026 there is no Apple statement and no fix. This is an independent measurement that puts concrete conflicting numbers on a problem previously described in general terms, and what it offers is a workaround rather than a correction.

The practical damage is decision-making. If you are deciding whether a large video project will fit, three tools disagreeing by more than 12 GB on one volume, plus a purgeable figure nobody can predict, means you cannot answer that question from the Finder. It also means the free space a backup or an installer reports having is not necessarily what it will get.

The other way space disappears

Worth pairing with the same-day report from Michael Tsai on August 21, 2026: runaway RTCReporting logs filled /private/var/root/Library/Logs with 74 GB, while rtcreportingd and fileproviderd each sat at almost 100% CPU, traced to Dropbox syncing.

That is the distinction to hold on to. On August 21, 2026 there are two separate ways a Mac reports the wrong amount of free space: an accounting problem in how macOS counts what it has, and an actual runaway consumer filling a directory you never open. The first needs a reliable measurement. The second needs you to find the process.

What to do today

1. When the number matters, take the container free space from diskutil apfs list in Terminal as your reference figure, which the August 21, 2026 write-up calls a generally reliable guide.

2. Treat the Finder and the Storage pane as indicative only, and do not act on a difference of a few gigabytes between them.

3. Allow headroom for purgeable space and for special files, because you cannot tell what the missing space is or when macOS will release it.

4. If free space is falling with no explanation, look for a runaway log directory or a process at full CPU before you start deleting your own files. In Activity Monitor, sort by CPU and look for a daemon you do not recognise.

5. Accept the cost of the workaround: it needs Terminal, it gives container-level rather than per-file numbers, and it still will not tell you what is holding the space.