[rducom]

Three changes to Low-Hanging Fruits: the list stops rearranging itself while it loads, each row shows its relative weight, and a new target covers stale temporary files.

Figures come from one developer Mac. They show scale; they are not general claims.

The list holds still

Before this change, rows arrived late and disappeared mid-load. Discovered targets (.NET, Editors, Browsers) only joined once the whole catalog was sized, and the go-build cache alone takes tens of seconds. Rows measuring 0 B were dropped as soon as they were sized. Reading the list while it settled was confusing.

• Stand-ins. Each discovery search is now a CleanupDiscovery.Pass carrying placeholders. Every target a search can plausibly produce is on screen from the first frame, as a dimmed Searching row in its final section. The search swaps each placeholder in place as soon as it lands, without waiting for catalog sizing.

• Nothing vanishes. A target that turns out empty keeps its place, reads Empty (a search that found nothing reads none found), and cannot be selected by hand or by Select all. On this machine the rows were identical, in the same order, at open and after 60 s (33 each).

• Stand-ins only where plausible. A placeholder never goes away, so it is only put up where its target can exist:

  • editors and browsers when their folder exists;
  • project output when its toolchain has left a trace in the home (~/.nuget, ~/.cargo, ~/.npm…).

  If that guess is wrong, the row arrives late; it is never missing.

• Sizing became a loop per load (sizeRemaining). Rows that land mid-loop join its queue, and walks still never overlap.

Weight bars

Each row has a bar sized relative to the heaviest row. Its heat runs green → amber → red, blending the stops of the existing capacity gauges (Theme.heatColor). Length and colour carry the same value, so colour is never the only signal. The tooltip and VoiceOver give the row's share of the total.

New target: stale temporary files

This covers the user's own leftovers in /private/tmp and $TMPDIR (TemporaryFiles.swift). A temporary folder is disposable by contract, so the only question is whether anything still uses an entry. An entry is offered only when all of these hold:

• it belongs to the user;
• it is a regular file or a directory. Sockets and FIFOs are live endpoints, and a directory containing one counts as in use;
• for 3 days, no file in it has been written or changed and no folder in it has been created. The ctime counts, because unpacked archives keep their original mtimes (npm stamps 1985);
• the walk could read all of it, and no filesystem is mounted inside;
• its name is not runtime state (hidden entries, com.apple.*, .lock/.pid), and it is not empty.

Granularity: a warm directory is looked into, down to depth 3, so the dormant parts of a live tree are still found. The motivating case is claude-<uid>/<project>/<session>, kept warm by today's session while it holds weeks of abandoned ones. Loose files are only offered at the top of a temporary folder.

A finding from this machine. macOS 26 runs com.apple.tmp_cleaner every night at midnight. It deletes files in /tmp that have not been read, written or changed for more than 3 whole days. Deleting them moves their folder's mtime to midnight. A first version of this rule counted directory mtimes and therefore saw every thinned folder as busy: it offered 318 MiB out of 17.5 GiB. Folders now count by creation time only, the same reason the scanner leaves directory mtimes out of newestMTime. The figure became 6.29 GiB (379 items). A test pins this behaviour.

Safety:

• A separate fence. Cleanable.Fence.temporary is checked by detect and clean; the home fence is not widened. A home-fenced target pointing into /tmp gets nothing, and a test covers that.
• Roots from confstr, never from the environment. The per-user folder comes from confstr(_CS_DARWIN_USER_TEMP_DIR), not from $TMPDIR: a TMPDIR pointing at the home would turn Documents into a "temporary file". No root may be /, contain the home, or sit inside it. /private/var/tmp is left out because it survives reboots on purpose.
• Re-check at clean time. Every entry is checked again just before deletion; the window may have stayed open for days. An entry that came back to life is left and counted as in use. The row is regenerable: false: badged not a cache, never selected by Select all, and named in the confirmation.

Performance: the walk uses getattrlistbulk with creation and change times. They are requested behind a new activityTimes flag, so the main scanner's buffer is unchanged. Below the decision depth, a subtree whose verdict is already "in use" is not read any further. Measured on this machine (release build):

Folder	Content	Walk
/tmp	17.5 GiB	0.24 s
$TMPDIR	262k directories	11.4 s

The main scanner takes 11.6 s on the same $TMPDIR: the cost is the filesystem's.

CleanupEngine.size(of:) now counts loose files, which only temporary targets carry.

Review focus

• TemporaryFiles.swift: candidates, select and the WalkState pruning in claim(). This decides what gets deleted outside the home.
• CleanupEngine.cleanTemporary: fence, ownership and the dormancy re-check before removeItem.
• FSAttr.enumerateDirectory: CRTIME/CHGTIME packing order (CRTIME 0x200 before MODTIME 0x400, CHGTIME 0x800 after). Both are gated, so the default buffer is identical to before.
• CleanupController.load / join / settle: stand-ins, in-place replacement, and .ready only once every search has landed and nothing is pending.

Testing

244 tests (+12, all passing on three consecutive full runs). Changes to existing tests:

• New TemporaryFilesTests. Because a fixture's ctime cannot be backdated, dormancy is exercised by moving now forward. One test sleeps 2 s, so that removing a file and the file's own times fall in different seconds.
• New controller test: stand-ins are visible and unselectable, the catalog is sized while a search is out, and stand-ins are replaced in place or marked none found.
• New discovery test: stand-in ids match the rows each search produces.
• Rewritten: emptyRowsAreDroppedOnLoadButKeptAfterCleaning became emptyRowsStayInPlaceButCannotBeSelected. reloadDuringCleanIsDeferredUntilBatchEnds now proves the reload ran through lastFreed instead of an emptied list.

The UI was checked on the running debug build: stand-ins at open, the same rows at open and once ready, bars, and the untruncated temp-files label. Nothing was cleaned during those checks.

Known gaps

• Open question: /tmp vs $TMPDIR. For /tmp, this target mostly gets ahead of macOS's own nightly cleaner by about a day. Its lasting value is $TMPDIR, which that cleaner never touches. Restricting it to $TMPDIR is a one-line change if preferred.
• explain (MCP) does not classify paths inside temporary folders yet. cleanup_targets lists the new row.
• Clean still waits for every search. On a $TMPDIR holding 262k directories, that is the ~11 s walk.
• While sizing runs, bars are relative to the heaviest row so far: the first row measured is red until a bigger one lands. The bars animate as they rescale.
• Empty catalog rows are now always listed (12 of 33 on this machine). If that reads as clutter, they can be grouped once sizing ends, at the cost of one reorder.