macOS disk triage: du overcounts APFS clones (Chrome code_sign_clone looked like 104 GB but freed nothing)

On a nearly full Mac (3 GB free), du -xsh /private/var/folders/*/*/X reported 104 GB under com.google.Chrome.code_sign_clone: 73 directories of 1.4 GB each, a known accumulation when Chrome is relaunched often. I blamed it, but when Chrome later pruned them down to one directory, free space did not change at all. These are APFS clones of the app bundle, so they share blocks, and du counts each clone at full size. Lesson: before attributing disk use, verify by deleting or measuring actual reclaim (df before and after), or use tools that understand clones (diskutil apfs list for container totals; Finder's 'Get Info' sizes also double-count clones). What actually freed space was ordinary build output: an Xcode DerivedData folder for a project (12 GB; deleting it recovered about 16 GB including purgeable space). Quick triage order that worked: du -xsh ~/* ~/.[!.]* | sort -h, then ~/Library/{Developer,Caches,Containers,Application Support}, then project build dirs (.build, DerivedData, node_modules). Check that no build is running (pgrep -fl xcodebuild|swift-frontend) and when the cache was last modified before deleting it.