17 GB of Junk That Wasn't Junk

We shipped a detector that found 16.9 GB of abandoned iOS simulator runtimes on a developer's Mac. It was confident. It was specific. It named the builds. It was also wrong. Those files were the backing images of two simulators that were still installed. This is the story of how a disk tool talks itself into that, because every step in the chain is a trap, and three of them are still quietly costing people space right now. Every number below was measured on one Mac between August 19 and 21, 2026, and you can reproduce all of it. :::disk-traps-ledger ### The junk macOS will not let you delete Every time Xcode downloads an iOS simulator, the system image lands in Apple's asset store, at `/System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/ .asset`, about 8–9 GB apiece. CoreSimulator, the service that runs simulators, keeps a registry of the ones it knows about. `xcrun simctl runtime list` prints it. That morning the registry printed exactly one runtime — iOS 26.5 — and the folder held three. The other two were iOS 18.2 and iOS 18.4, 8.4 and 8.5 GB, downloaded in early 2025. So: two large images, nothing in the registry pointing at them. That is the textbook definition of an orphan, and it is exactly what our scanner concluded. The first surprise is that you cannot delete them anyway: ``` $ ls -lO /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/ drwxr-xr-x@ 5 _nsurlsessiond wheel restricted 160 Feb 4 2025 3ee34d77….asset drwxr-xr-x@ 5 _nsurlsessiond wheel restricted 160 Apr 8 2025 6fb1e5fe….asset ``` `restricted` is a System Integrity Protection flag: the folder is off-limits to everyone, `sudo rm` included. The standard advice on the internet for this problem is "disable SIP, reboot, delete, re-enable SIP." We are not going to ship that to anyone. What *can* remove them is Apple's own runtime service. You ask it to adopt the image back into its registry — `simctl runtime add --move` — and then delete it by UUID. The daemon does the removal itself, with its own entitlements, no password. ### The refusal that costs you 8 GB The adoption refused: ``` $ xcrun simctl runtime add …/092-10337-196.dmg --move SimDiskImageError code=14: Cannot copy the image because the disk is almost full ``` There were 24.7 GB free and the image is 8.4 GB. So we went looking in the daemon itself, since its log lines are redacted: ``` $ strings …/CoreSimulator.framework/…/simdiskimaged minFreeSpace = %llu Because source is on the same volume as inbox and clones are supported will allow a lower free space limit ``` That sentence is the whole answer. When the service can make an APFS clone of the source — copy-on-write, instant, zero extra bytes — it barely needs free space at all. When it cannot, it falls back to a full byte-for-byte copy and demands the image's size plus a large reserve on top. It cannot clone out of the SIP-protected asset store. So the one folder you are not allowed to delete is also the one folder Apple's own tool has to copy in full before it will help you. We confirmed the mechanism from the other side: a plain 9 GB file in `/tmp`, with only 14.6 GB free, sails past the same precheck. Same volume, same size, not SIP-protected — no complaint. Then the part that actually matters. **A refused `runtime add` is not a no-op.** By the time it decides the disk is too full, the daemon has already copied the image into its own store and registered it as an `Unusable` runtime, and it leaves both behind. Three refusals left three 8.38 GB copies in `/Library/Developer/CoreSimulator/Cryptex/Images/`, plus a 9 GB copy in its `Inbox`. Thirty-four gigabytes of residue, produced entirely by operations that reported failure. No tool lists it — `du` on your home folder never sees it, and the runtime that owns it does not appear in the plain `simctl runtime list` output. ### The junk that wasn't junk At this point the honest summary was: 16.9 GB that cannot be deleted by anyone, and an adoption route that makes things worse every time it fails. That summary was wrong, and one command shows why. `xcrun simctl runtime scan-and-mount` is Apple's own repair verb. It tells CoreSimulator to walk its own storage and re-adopt anything it has lost track of. It takes about a tenth of a second. After running it, the registry looked like this: ``` $ xcrun simctl runtime list iOS 18.2 (22C150) - 87410283-… (Ready) iOS 26.5 (23F77) - 8E56E104-… (Ready) iOS 18.4 (22E238) - 10B15C7F-… (Ready) Total Disk Images: 3 (24.2G) ``` One runtime became three. And the full JSON record for iOS 18.4 contained a field the summary listing never shows: ``` parentImagePath = /System/Library/AssetsV2/…/6fb1e5fe….asset/AssetData/090-44150-318.dmg ``` The "orphaned" asset was the parent image of an installed, working runtime. CoreSimulator had simply lost the registration for the two Cryptex bundles holding iOS 18.2 and 18.4, and while that registration was missing, nothing on the machine claimed the assets. The bytes never changed. Their status did. The cleanup was then free. `simctl runtime delete ` on the three `Unusable` leftovers cleared all 34 GB of staging residue — no password, no staging space, and it emptied the `Inbox` on the way out. The two 18.x runtimes now show up in our scan as what they actually are: one unused, one superseded by a newer build, both deletable by UUID. ### And then we were wrong again Deleting them frees almost nothing. We ran it through our own executor and measured: removing the iOS 18.2 runtime returned **21 MB**. Not 8.4 GB — 21 MB. The registration disappeared, the bundle unmounted, and the 8.4 GB `.asset` sat exactly where it was. `simctl runtime delete` never removes the MobileAsset it was installed from. Apple even ships a `--keep-asset` flag, which strongly implies the opposite, and on a Cryptex-backed runtime it makes no difference at all. So the space is reachable by exactly one route after all: `runtime add --move`, relocating the image out of the protected store — which cannot clone, and therefore wants the image plus about a tenth of the volume free. On a 494 GB disk with 16.9 GB of dead simulators, that is roughly 58 GB you must find first. The chicken and the egg were real the whole time. What was wrong was the label, not the arithmetic. Two more things fell out of measuring it. Deleting a runtime and rescanning brought it *back* — our own repair step re-adopted the now-parentless asset under a fresh UUID, undoing the deletion. And a delete that had actually succeeded was reported as a failure, because CoreSimulator had not republished its registry inside the 15-second window we waited. Both are fixed; both existed only because we finally measured the filesystem instead of the registry. One last Apple oddity, for anyone writing their own cleanup: `simctl runtime delete --notUsedSinceDays 90` matched nothing here, even though both 18.x runtimes have `lastUsedAt` of `null`. Apple's own "delete what you haven't used" filter skips the runtimes you have never used at all. ### One folder, two names While building the chart that shows where the disk went, an internal check started firing: the children of the Developer category summed to 18.1 GB *more* than the category itself. That should be impossible — every child is measured from inside its parent. It fired 502 times, and the excess was always exactly 18.1 GB. The cause is a firmlink. Since Catalina, macOS keeps the system on a sealed read-only volume and your data on another, then stitches them together so the filesystem looks like one tree. Some paths end up with two spellings that are literally the same directory: ``` $ stat -f '%d %i %N' /System/Library/AssetsV2 /System/Volumes/Data/System/Library/AssetsV2 16777233 210916113 /System/Library/AssetsV2 16777233 210916113 /System/Volumes/Data/System/Library/AssetsV2 ``` Same device, same inode, two names. Our whole-disk pass recorded the simulator folder under one spelling; the scanner reported the runtimes under the other; a string comparison said they were different places, and 18.1 GB got added on top of a category that already contained it. Any tool that reconciles two measurements by path — and every disk tool does — has this bug unless it compares through the firmlink table. The lesson is older than APFS: two strings that differ can still be one file. ### The 46.7 GB that was never there Run `du` on Chrome's update leftovers and it reports 46.7 GB across 34 directories named `*.code_sign_clone`. Delete every one of them and your free space moves by zero. They are APFS clones. Chrome makes a copy-on-write snapshot of its own bundle during code signing, and the clone shares every block with the original until one of them is modified, which never happens. `du` reports the logical size of what it sees, and what it sees is a 1.4 GB application, 34 times. A cleaner that ranks by `du` puts these at the top of the list, lets you "free" 46.7 GB, and leaves you staring at an unchanged number. We measure allocated blocks instead, and skip clone directories in the overview entirely — promising 46.7 GB and delivering nothing is worse than never mentioning them. ### The delete that arrived a second late The last one is small, and it bit us on the day we wrote this. Our receipt after a clean does not report the size of what was removed. It reports the change in free space *observed* on the volume, sampled right after the last file goes away, because that is the only number a user can check against Finder. For months that worked. Then someone deleted two 9 GB folders and the receipt said `freedBytes: 0`. The files were gone. The history entry recorded 17.5 GB permanently deleted. The volume's free space, read 375 milliseconds later, had not moved at all. APFS reclaims the blocks of a large tree asynchronously. For a few hundred megabytes it is effectively instant; for tens of gigabytes it takes seconds, and a sample inside that window sees nothing. The headline number at the top of the window, which read the same value once, stayed put too — which looks exactly like a delete that did not work. The fix is dull: sample longer when more bytes were processed, stop when the observed change stops growing, and re-read the headline on a short schedule after anything that frees space, whichever button triggered it. ### What we changed The detector is not gone; it is no longer allowed to accuse anything on the strength of a registry it did not verify. Before Mint calls any simulator storage an orphan, it now asks CoreSimulator to re-adopt its own storage first, and re-reads the registry afterwards. On this Mac that turns two undeletable "leftover runtime images" into two ordinary rows you can remove by UUID, in one click, with no password. And when the adoption route does run and Apple refuses it, Mint now sweeps up its own staging residue instead of leaving 8 GB behind per attempt. None of these traps are bugs in macOS. Sealed system volumes, firmlinks, copy-on-write clones, lazy reclamation and a self-healing runtime registry are all good engineering, and all invisible when you are simply using the machine. They only become a problem for a program that claims to know where your space went, because each one opens a gap between what a folder weighs and what deleting it gives back. The cheap way to build a disk cleaner is to walk the tree, sort by size, and put checkboxes next to the big things. Every trap above is a way that approach produces a number that is wrong in the user's favour, right up until they click. And the one that cost us the most was not a measurement error at all. It was trusting an answer — "nothing references this" — without asking whether the thing giving the answer had finished counting. --- *All measurements were taken with Mint's read-only scan hooks on one developer Mac in August 2026 and can be reproduced on yours. The companion piece on what coding agents leave behind is [Your Coding Agent Is Eating Your Disk](/build-journey/agents-are-not-a-black-box).*