macOS Cleaner

Phase 2 entry gate

A real 2026-09-19 run followed the Phase 1 machinery to the letter and still shipped three bad plans: it proposed preserve-by-default caches (npm _cacache, Playwright browsers, Homebrew) as a "low-risk combo" because the rule lives in references/cleanup_targets.md — a file the discovery workflow never opens; it proposed uv cache prune as zero-impact from a --help line plus size ratios, never verifying semantics or the installed version; and it led with 2 GB items beside a 91 GB candidate because no free-space target had been set. The rules that would have caught all three already existed in this skill — in a reference the procedure never opened, which makes them not rules in practice. A prose checklist is only one level better than the reference it summarizes: an independent review of the first draft of this gate found thirteen blocking defects, the deepest being that the gate itself had no mechanical enforcement. Step 4 is therefore a script, not a promise — run it, or the plan does not exist.

1. State the outcome being reported. For a cleanup target, use the user's exact value. Without one, deliver the occupancy inventory or ranked decision list; do not invent a capacity target or claim it has been met.

2. Open references/cleanup_targets.md and classify every candidate the discovery produced into this table, written to a file (step 4 parses it):

   Target	Nominal size	Physical confidence	Class	Governing rule (verbatim quote)	Expected physical release + basis	Restoration cost	Verdict
   exact target: a path, a service setting (e.g. AssetCacheManagerUtil or a plist key), or a supported control (e.g. chrome://settings/clearBrowserData)	du output	path-accounted (Phase 1's label for APFS-shared or nominal du) / sparse-aware / engine-reported (a subsystem's own accounting, e.g. Docker system df) / unknown — never enter a nominal number as release	PRESERVE / PROPOSABLE / REBUILDABLE / USER-DATA / USER-DECISION	a quote from cleanup_targets.md, the route's dedicated reference, or this skill's own SKILL.md (the checker verifies every quote against the whole bundle and prints per-file provenance, so SKILL.md-only quotes stay visible); "no rule found" is itself a finding	an estimate plus how it was derived; unknown is an allowed value	redownload/rebuild cost, or n/a	in action set / not in action set / unlocked by user (quote the direction)

   • PRESERVE — every row of the preserve-by-default table in cleanup_targets.md (opened in this step, quoted in the table — step 4 verifies the quotes, so a fabricated quote fails). Out of the action set unless (a) verified never-used evidence exists for the target, or (b) the user explicitly names that target for cleaning knowing the cost. Accepting a cost you stated is not (b): the user must name the target themselves.
   • PROPOSABLE — verified never-used evidence (a dead project, an explicit user statement, an artifact check). Size ratios are not evidence: "the cache holds 586 environments, 28 project venvs exist" proves nothing about the other 558.
   • REBUILDABLE — not in the preserve-by-default table, has a supported management command or cheap rebuild (Homebrew, pip), restoration cost stated in the row.
   • USER-DATA — never in an action set; report the location, never a command.
   • USER-DECISION — the user's workflow or ownership knowledge decides; ask, don't propose. Also the home for targets no reference covers ("no rule found"): the plan asks before proposing anything for them.

   If no reference anywhere covers a target, say "no rule found" and classify it USER-DECISION — do not stretch an unrelated rule to cover it.

3. Apply the gate rules. Step 4's checker enforces each one mechanically — that is what makes them rules rather than reminders:

   • The action set contains exactly the rows marked "in action set" plus rows marked "unlocked by user" with the user's direction quoted. No state-changing command may name a target absent from the table. PRESERVE rows enter the action set only via never-used evidence or explicit user direction (step 2).
   • The plan leads with the in-action-set row holding the largest expected physical release — unless the table marks another row as the user-visible hotspot or bottleneck (the thing the disk pressure is actually about) with a stated reason. Any other lead row fails this gate; that is the small-fish failure, not conservatism. Never rank by nominal size alone: nominal is not release, and for shared-extent candidates the release is unknown until deletion and df readback (step 2's labels).
   • Every destructive command records: the owning tool's installed version (for an application control or a service command, the owning application or service); the semantics source (the tool's own help or documentation — if the only available source is this skill's transcription, say so and verify cheaply against the live tool); and for category-wide commands — scope is an entire class of objects with no per-object selection; the skill's existing term is prune-family — a known-issue check. uv cache prune, npm cache clean, brew cleanup --prune, and the Docker prune family are category-wide by definition.
   • Commands the skill declares unsanctioned (uv cache prune, npm cache clean, the Docker prune family) may not appear in the action set even when every other rule passes — not for any size, not for any version. npm cache clean joins the list because it wipes the preserve-by-default _cacache wholesale. Only an explicit user instruction for that exact command moves it, and it runs in Phase 3 as a directed action, never as a proposal.
   • Zero in-action-set rows is a legitimate outcome: deliver the ranked decision list (PRESERVE and USER-DECISION rows with their unlock costs and evidence) and ask the user which to unlock. An empty action set with a decision list passes; inventing rows or downgrading PRESERVE to fill it does not.

4. Write the plan to a file, then run the checker before sending it:

   uv run scripts/check_gate_plan.py --table <gate-table.md> --plan <plan.md>

   Exit 0 is necessary, but does not certify an unrecognized command. Read the examined-command count and every coverage diagnostic: a proposed deletion with zero commands examined is unchecked. Use a recognized exact form or independently resolve that command's target coverage and semantics before execution; do not treat a PASS beside “coverage incomplete” as approval. The checker verifies table classification, verbatim rule quotes, recognized destructive-command targets, action classes and unlock rules, preserve-by-default protections, category-wide exclusions, release ranking, and tool verification. It recognizes uv run and Python calls to safe_delete.py with relative or absolute script paths and checks every literal target separately; unresolved batch files and shell expansions fail coverage. A failing run names the violated rule — fix the plan; do not weaken the checker.

   Five failure shapes the checker reliably catches, measured while getting a real 18-target plan to exit 0 — all five are plan-side fixes, never checker-side:

   • Path form mismatch (target_coverage): the table must carry the same full absolute path the command uses; a ~/ shorthand row does not match a command that names /Users/….
   • Two targets on one row: a row naming two paired targets fails to parse — split into one row per target.
   • "du nominal" in the release column reads as a nominal number and is rejected; state how the expected release was derived instead, or enter unknown.
   • A single-line osascript inside a table cell gets cut into pipe-delimited chunks the command matcher cannot reassemble — put the canonical multi-line osascript in the plan's code block, not in a table row.
   • Naming the command in prose (an intro sentence mentioning osascript) is parsed as a command start with no matching row — keep command names out of prose, and start table rows with a path, not a label (a row leading with OrbStack fails).

Report observed values rather than inferred properties. Use references/report_templates.md for the long-form layout and include these fields for every proposed action:

Classify findings by consequence, not by how tempting the number is:

• Rebuildable cache: deletion loses only a local copy, but state the redownload or rebuild cost. Rebuildable is not proposable by default: the preserve-by-default table in references/cleanup_targets.md (opened and quoted in the Phase 2 entry gate) decides; those targets stay out of the action set until never-used evidence or explicit user direction moves them.
• User decision required: value depends on the user's workflow or ownership knowledge.
• Preserve: user data, credentials, database state, active configuration, or anything whose role is uncertain.

Do not call a cache “absolutely safe” merely because software can regenerate it. Regeneration time, bandwidth, authentication, and offline availability are real costs.

Phase 3: execute the confirmed plan

Immediately before the first state-changing command:

1. Reconfirm the target identity and current disk state.
2. Re-query the objects or subsystem status; cleanup plans expire when live state changes.
3. Recheck protected-service health.
4. Compare the approved commands and exact target set with the commands about to run. Any wider or different target set requires new approval. A separately preserved item becoming inactive does not invalidate the plan when it remains explicitly excluded and the approved target-set hash still matches.

Keep approvals and exclusions attached to the original inventory. “Delete these; keep the rest” approves only those targets; “continue looking” resumes read-only discovery. If some approved paths have disappeared, stop the batch and report original, remaining and missing counts. Proceed with a smaller set only after proving it is a subset of that inventory with unchanged identity/content and consequences; the existing authorization can cover that verified remainder. A newly generated replacement at the same path is a changed target. Do not substitute a peer's inactivity report for user approval, or report already-absent paths as deleted by this run. The legacy helper still stops on missing targets; reconcile the plan before invoking it again.

If the approved plan includes creation of a local before/after report artifact, capture the before snapshot now, after approval and before the first cleanup command:

uv run scripts/cleanup_report.py --snapshot before

This writes under ~/.macos-cleaner, so list it in the plan. It is optional and local-target only; direct df -k/-h readings remain the source of truth. Never run it on the controller Mac as a substitute for measuring a remote target.

Run one state-changing command at a time. Read the result before sending the next command. After each command, run the postcondition that can distinguish success from partial success.

For an exact ordinary file that is not user data, application state, a database, or a protected path, prefer a recoverable Finder Trash move after the user confirms the exact path:

/usr/bin/osascript \
  -e 'on run argv' \
  -e 'tell application "Finder" to delete (POSIX file (item 1 of argv))' \
  -e 'end run' -- "<exact-path>"

Moving to Trash usually releases no physical space until Trash is emptied; state that in the plan.

Remote and headless targets: the Finder channel needs Automation consent, and ssh-originated AppleEvents hang without it. Measured 2026-10-07 on a headless worker: an ssh session driving the osascript Trash move above blocked indefinitely — nine targets in, target one still present, Trash unchanged, and even a harmless Finder probe (count of items) never returned. There is no error to catch; the tell is the silence. Before relying on the Finder channel over ssh, run a bounded probe first and treat a hang as the channel being closed, not as a slow Finder. Stock macOS has no timeout(1), so bound it in AppleScript itself:

/usr/bin/osascript \
  -e 'with timeout of 1 second' \
  -e 'tell application "Finder" to count of items of trash' \
  -e 'end timeout'

The same-volume fallback is a quarantine move, not Trash: mv each exact approved target to a directory on the same volume (<approved-dir>/_quarantine-<date>/), writing a MANIFEST (original path, size, timestamp) beside it — the original path is what an mv-back recovery needs. It shares Trash's safety properties — same-volume mv is metadata-only, fully recoverable, and releases no space until a separately approved permanent pass — and it needs no Automation consent. Keep the two phases split exactly as with Trash: the quarantine move and the later permanent deletion are separate approvals, and the plan must name the quarantine location and the MANIFEST. The Phase 2 plan checker recognizes the quarantine form specifically (a leading mv, tolerating a command-table cell's backtick, whose first argument is a quoted or path-ish token and whose command carries the _quarantine- marker) and binds each such command to its table row exactly as it does the osascript Trash form; an ordinary mv, git mv, sudo mv, a non-quarantine rename, or a prose sentence that merely starts with the word "mv" is deliberately not recognized, so a quarantine command still states each target explicitly in the table.

scripts/safe_delete.py is a legacy permanent-deletion helper with an interactive prompt and a limited system/credential denylist. It does not move to Trash, check every user-data root, detect open files, or independently prove reclaimed bytes. Use it only when the exact non-user-data target and irreversible deletion were explicitly approved:

uv run scripts/safe_delete.py <exact-path> [<exact-path> ...]

Do not use this helper for user documents, application-managed caches such as Apple Content Caching, databases, credentials, or any target whose role is uncertain.

Two narrow Finder-Trash branches remain available without weakening those exclusions:

• For an exact inactive application cache with no verified supported management control, follow the named-cache discovery/in-use protocol in references/cleanup_targets.md, explain the rebuild cost, and obtain explicit approval for that exact cache path.
• For duplicate files inside an exact approved user-data root, first show each duplicate set's size/hash and every path. The user must name the copy to keep and each copy to remove. Move only those confirmed files to Finder Trash; never use the permanent helper, an automatic duplicate-selection flag, all, a glob, or a directory-level target. Verify the source paths moved to Trash, and state that physical space is not released until Trash is separately reviewed and emptied.

Phase 4: verify and observe

Verification must cover all clauses of the approved plan:

• Re-read df -k and df -h; report the net change over the measured window separately from the path-accounted size removed. Check timestamps and kern.boottime: a reboot, swap release or concurrent writer makes this a mixed window, not proof that deletion caused the full change. Report the unexplained remainder rather than forcing it onto a directory.
• Re-query the cleaned subsystem's activation, configuration, and physical usage.
• Re-resolve each protected service's PID, listeners, launch mechanism, and health probe. A healthy disk does not prove the service survived. Report a failed invariant and stop the affected action; disk cleanup does not authorize restarting services, terminating other sessions, or repairing an unrelated application.
• Observe at bounded intervals when APFS accounting can lag or the source may refill. Record each timestamp and value.
• If the free-space target is missed, stop all deletion. Begin a second read-only analysis and rank remaining sources by measured physical allocation.

Never report “fixed” when only the command exit code is known. A successful cleanup requires both the intended state and the protected invariants.

For a local target whose before snapshot was captured by the helper, generate the comparison with:

uv run scripts/cleanup_report.py --snapshot after --compare

Resources

Load only the branch relevant to the current task:

• references/apple_content_caching.md — Apple Content Caching diagnosis, unit interpretation, supported remote controls, confirmation plan, and post-cleanup verification.
• references/chromium_code_sign_clones.md — Chrome/Chromium/Edge code-sign-clone semantics, nominal-versus-physical reporting, exact inactive-target manifests, cleanup verification, and recurrence prevention.
• references/cleanup_targets.md — cache, log, application, developer, large-file, and Time Machine target semantics.
• references/proving-redundancy-before-deletion.md — the evidence ladder for large data folders (duplication → creation-origin → references → session-history census → .DS_Store → project decision records). Load BEFORE proposing deletion of any big project-asset / media / dataset directory; a size ranking is not evidence.
• references/growth_attribution.md — "what grew lately" questions: finding and calibrating a baseline export, the not-scanned trap, which file timestamp answers "arrived since", reconciling path-accounted deltas with df (swap, snapshots, short-lived copies), and naming the writer.
• references/docker_analysis.md — per-object Docker and OrbStack analysis, database-volume safeguards, and refill root-cause diagnosis.
• references/mole_integration.md — TTY workflow for interactive Mole analysis and preview.
• references/report_templates.md — long-form general and Docker report templates.
• references/safety_rules.md — blocked paths, confirmation, recovery, and file-deletion safety checks.
• scripts/analyze_caches.py — bounded cache inventory; retain unknown measurements and diagnostics, treat incomplete subtotals as known lower bounds, and interpret exit 1 as incomplete measurement or unresolved developer paths rather than zero usage.
• scripts/check_gate_plan.py — Phase 2 entry gate checker: parses the classification table and the plan, verifies governing-rule quotes against the references, destructive-command target coverage (with unrecognized command forms counted and reported), action-set class and unlock rules, the preserve-by-default downgrade cross-check, category-wide exclusions, the lead-row ranking rule, and tool verification. Exit 0 is required before a plan may be sent. Its command whitelist is a declared limitation: forms outside the list are reported as unrecognized rather than silently ignored.
• scripts/analyze_code_sign_clones.py — read-only current-user code-sign-clone inventory; after approval it can revalidate an exact candidate SHA and write a non-overwriting batch manifest.
• scripts/find_app_remnants.py — application-remnant candidates; reads its fixed Applications and ~/Library roots, so require that scope first.
• scripts/analyze_large_files.py — large-file discovery inside an approved path.
• scripts/analyze_dev_env.py — Docker/package-manager inventory plus fixed common-project-root .git sizing; require that full read scope first.
• scripts/safe_delete.py — legacy guarded permanent deletion for exact approved non-user-data targets; it is not a Trash or recovery tool.
• scripts/cleanup_report.py — local-target before/after reporting for /System/Volumes/Data by default, with an explicit --volume override.

Do not use this skill when

• The target is Windows or Linux.
• The requested action requires disabling SIP or bypassing macOS protections.
• The user asks for silent or automatic deletion without an auditable scope and confirmation gate.
• The task is only to tune application behavior and has no disk-space diagnosis or recovery goal.