Uninstall UTM on Mac

Shut down and back up every virtual machine you want to keep before uninstalling UTM. The default VM folder is ~/Library/Containers/com.utmapp.UTM/Data/Documents, but a VM can be moved elsewhere, including an external drive. Mole lists the VM container unchecked and removes the Homebrew cask without zap; selecting the container or running Homebrew zap yourself deletes the VMs inside it, not a VM stored outside it. These steps cover the official DMG, the Homebrew cask utm, and the same-identity Mac App Store build described in UTM’s public source.

Back up your virtual machines first

Save work and shut each guest down normally from its operating system, then confirm it has stopped; forced power-off can corrupt its disk. In the VM list, secondary-click each VM and reveal its .utm package in Finder to confirm its actual location. Quit UTM, then copy the complete packages to a different folder or drive outside UTM’s container and open the copies to check their contents. A second copy inside the same container is deleted with it. VM actions and shutdown controls explain these steps.

Quit UTM and shut down running VMs

After the stopped VMs are backed up and UTM has quit, move UTM.app from Finder’s Applications folder to the Trash. Homebrew users can use the ordinary cask command below instead. UTM has no separate login item or helper to remove.

Where UTM keeps its data

The three cache/temp paths are separate from Data/Documents: Mole's Clean tab only ever touches those three, never the Documents folder where your VMs live.

Check the result

Run these read-only commands in Terminal:

pgrep -ilf utm
ls -d ~/Library/Containers/com.utmapp.UTM
ls -d ~/Library/Containers/com.utmapp.UTM/Data/Documents

With no command error, no output from pgrep means no full command line matched utm; a QEMU process whose command line lacks that text is outside this check. ls -d proves only that the container or its Data/Documents directory exists, not that a complete VM package is inside. Inspect the actual .utm packages and the independent backup made above. "No such file or directory" concerns that exact path, not VMs stored elsewhere; a permission or other read error leaves the check unresolved.

If you installed it with Homebrew

Because UTM's container holds your virtual machines, Mole never adds --zap when it removes the utm cask, whatever you tick. Running brew uninstall --cask --zap utm yourself runs the cask's own zap list, which trashes ~/Library/Containers/com.utmapp*, ~/Library/Group Containers/*.com.utmapp.UTM, ~/Library/Application Scripts/*com.utmapp*, plus its preferences and saved state, regardless of what you left checked or unchecked in Mole's review screen. That means every VM in Data/Documents goes to the Trash with the rest of the container. Copy your VMs out first, or skip the zap step entirely:

brew uninstall --cask utm

Homebrew UTM cask

What Mole lists

~/Library/Containers/com.utmapp.UTM (which holds Data/Documents and every VM inside it) is listed but not selected, because Mole treats it as your data rather than app state. ~/Library/Application Scripts/com.utmapp.UTM, the preferences and the saved window state are selected by default; the group container ~/Library/Group Containers/WDNLXAD4W8.com.utmapp.UTM and its Application Scripts peer are listed but not selected. The three cache/temp paths above show up separately in the Clean tab, selected by default there as ordinary regenerable cache; Clean itself never reaches into Data/Documents.

What this test covered

UTM was installed from the Homebrew cask utm and uninstalled with a development build of Mole on September 17, 2026. That build had Full Disk Access enabled, so the residue review screen was skipped and the removal went straight through; official-download users still see the review list described above. The Group Container, sandbox Container, and Application Scripts rows were all removed cleanly with no leftover found beyond what is already listed. No virtual machine was created for this test, so removing a populated Data/Documents folder was not directly observed; the container-selection behavior above comes from reading Mole's scanner code, not from watching a real VM get deleted.