macOS - Configuration - Clean /Tmp and /Library/Caches Directory

What the macOS cache and tmp purge Worklet does

This Automox Worklet™ reclaims disk space on macOS endpoints by clearing the contents of /tmp and removing aged entries from /Library/Caches. The Worklet targets two directories that grow without bound on long-running Macs. The /tmp directory holds session scratch files, application download buffers, and installer payloads that processes never clean up after themselves. The /Library/Caches tree holds per-application cache stores that accumulate over months of normal use.

The Worklet runs as bash and uses the standard macOS find utility at /usr/bin/find. On /tmp it deletes every file and subdirectory using find /tmp/* -print -delete. On /Library/Caches it scopes deletion to entries older than 30 days using find /Library/Caches/* -mtime +30 -print -delete. The age gate protects cache data that active applications still rely on. When a user next opens Safari, Xcode, or Photos the application keeps its warm cache and only the abandoned entries are gone.

Both phases echo every deleted path to standard output, which the Automox agent captures in the activity log for the policy run. The Worklet reports exit code 0 on success and exit code 1 if either directory cannot be cleared, so failures surface in Automox reporting rather than silently consuming the schedule slot. The Worklet is idempotent, which means a second run on an already-clean endpoint completes in milliseconds and emits a no-changes-required message.

Why purge /tmp and stale caches on macOS fleets

Disk pressure on a Mac is rarely caused by user files. It is caused by directories the user cannot see. The /tmp tree fills with installer payloads from unattended package updates, partial download buffers from browser sessions, and scratch files that crashed processes left behind. The /Library/Caches tree grows quietly as Spotlight, Photos, Mail, Safari, Xcode simulators, and Adobe products write multi-gigabyte working sets that never expire. When the volume crosses the macOS low-disk threshold the user sees Time Machine snapshots stall, Photos library imports fail, and Xcode builds error out with no space left on device.

Reclaiming disk on macOS normally waits for a help desk ticket about a "Your startup disk is almost full" prompt, and by then the user has already wasted an afternoon hunting for files to delete. Schedule this Worklet on a weekly cadence against the macOS maintenance policy so /tmp and stale entries under /Library/Caches are purged before the prompt ever appears. The deletion record in the Automox Activity Log gives you per-endpoint evidence of what ran, which feeds storage trending and refresh planning.

How the macOS purge cycle works

1. Evaluation phase: The Worklet runs find -L /tmp/* to detect any files or directories under /tmp, and find /Library/Caches/* -mtime +30 to detect cache entries with modification times older than 30 days. A combined zero result exits 0 and the endpoint is reported compliant. Any non-empty result exits 1 with a message naming which directory needs work, and Automox schedules remediation on the next policy slot.

2. Remediation phase: The clear_tmp function runs find /tmp/* -print -delete to remove every entry under /tmp. The clear_cache_library function runs find /Library/Caches/* -mtime +30 -print -delete to remove cache entries beyond the 30-day window. After each pass the Worklet re-evaluates the directory. A directory that still reports content triggers exit 1 with a pointer to the Automox activity log. A clean directory yields exit 0 and a per-path deletion record in the run output.

macOS purge prerequisites

• macOS endpoint with the standard filesystem layout, including /tmp as a symlink to /private/tmp and a populated /Library/Caches tree

• Root execution context, which the Automox agent already provides under launchd; no parameters or policy variables are required

• Bash 3.2 or later and the system find binary at /usr/bin/find, both shipped by default on every supported macOS release

• Awareness that the Worklet does not stop running processes. Files held open by a live process are unlinked but space is reclaimed only after the process exits or the endpoint reboots

• FixNow compatibility is available on this Worklet for an on-demand purge from the Automox console when a user reports a disk-full condition

Expected disk state after the purge

After remediation the /tmp directory is empty and /Library/Caches contains only entries with modification times inside the last 30 days. Per-endpoint reclaim varies with usage patterns, but the typical recovery on a developer workstation running Xcode simulators or an end user Mac with heavy browser usage falls between 500 megabytes and several gigabytes. The activity log records every deleted path, which serves as audit evidence that the policy ran and what it touched.

Confirm the result from the command line with df -h / to read free space on the boot volume, or with du -sh /Library/Caches to confirm the post-purge cache footprint. Re-running the policy on the same endpoint produces the no-changes-required message and exit 0, which is the steady state the schedule should hold. Cached working sets rebuild on first use, so user-facing applications take a one-time cold-cache hit on the next launch and resume normal performance after that.