Automox downloads third-party installers to a temporary location, runs them, and cleans up afterwards. Operating system updates work differently: Automox initiates the installation, and the operating system's own update mechanism handles the download, the cache and the cleanup. That distinction explains most questions about disk space after patching.
Who owns what
- Third-party software patches. Automox retrieves the installer, places it in its temporary working directory, executes it, and removes the file when the run finishes.
- Operating system updates. Automox orchestrates and initiates the installation. Windows Update on Windows, and Software Update on macOS, own the rest of the process, including where files are downloaded, how long the cache is retained, and when it is cleared.
Automox does not host its own patch repositories. Content is retrieved from the vendor's own sources, or from your internal update server where one is configured.
Storage locations
- The Automox working directory, used for third-party installers and script execution. Its location can be changed if needed, see Change Automox Script Execution Location.
-
Windows Update locations, which Automox does not manage:
C:\Windows\TempC:\Windows\SoftwareDistribution
Disk usage growing after patching
It is expected that Windows update files remain on a device after patching completes. The directories above are managed by Windows Update and are not always cleared immediately after installation. Separately, the component store keeps superseded versions of updated components so that updates can be uninstalled, and it grows over time on any patched Windows device.
Automox does not clear these locations, because doing so would interfere with a process Windows owns, including its ability to roll back an update. If you need space reclaimed on a schedule, use the mechanisms Windows provides for it:
- Storage Sense, which can remove temporary and update files automatically.
- Disk Cleanup, including its Windows Update cleanup option. See Disk Cleanup in Windows.
-
Component store cleanup with DISM, which reclaims the largest amount on long-lived servers:
Dism.exe /Online /Cleanup-Image /StartComponentCleanup
See Clean up the WinSxS folder for the available options. Adding
/ResetBasereclaims more space but removes the ability to uninstall previously installed updates, so treat that as a deliberate decision rather than routine maintenance.
If you want this applied across a fleet, a Worklet is the appropriate tool, scheduled outside your patch window so cleanup does not run against an update that is still finalizing. Test on a small group first, and confirm your rollback requirements before using /ResetBase.
When third-party installers are left behind
Automox attempts to remove every installer it downloads, but some files can remain:
- Interrupted execution. If a device restarts or the process is terminated mid-run, cleanup does not complete.
- Restrictive permissions. Some vendor installers create files the agent cannot subsequently remove.
- Installers that unpack elsewhere. A vendor package that extracts to its own location outside the Automox working directory is not covered by Automox cleanup.
Leftover installers are typically small compared with the Windows update cache, so if you are investigating significant disk growth, look at the Windows locations first.
Summary
- Third-party installers are downloaded, executed and cleaned up by Automox.
- Operating system update files are downloaded, cached and cleaned up by the operating system.
- Update files remaining after patching is normal, not a sign of a failed run.
- Reclaiming that space is done with the operating system's own cleanup tools, which can be deployed with a Worklet.