# Uninstall Mac Apps Installed from a .pkg Package

> A .pkg installer leaves a receipt and files outside the app. Read the receipt with pkgutil, remove only what belongs to that product, and forget the receipt last.

Published: 2026-09-06 | Updated: 2026-09-26

An app that arrived as a `.pkg` installer is not the same thing as an app you dragged out of a disk image. The installer ran as root, it could write wherever the package told it to, and it left a record of what it installed in the Installer's receipt database. Dragging the app to the Trash removes one of the folders that record lists and leaves the rest, including the record itself. This article is about that case: how to tell a package installed the app, how to read what it put on disk, what to remove and what to leave. If Finder refuses outright, or the app comes back after you delete it, start with [when a Mac app will not uninstall](https://mole.fit/blog/mac-app-wont-uninstall) instead, and for an app you dragged in yourself, [the complete uninstall guide](https://mole.fit/blog/how-to-completely-uninstall-apps-on-mac) covers the usual path.

## Why the Trash is not enough

A package can put files next to the app, not only inside it. When I reinstalled a batch of apps from their official installers and removed them again, the official Zoom package left three launchd jobs and a privileged helper, `us.zoom.ZoomDaemon`, outside `zoom.us.app`. Logi Options+'s installer also installed a second product, LogiRightSight, with its own receipt and its own launch agent. DisplayLink Manager added a launch agent to `/Library/LaunchAgents`. Microsoft Office installs a shared frameworks package that Word, Excel and PowerPoint all load, and Microsoft AutoUpdate plus a licensing helper come along with it. None of those move when the app bundle does.

The receipt does not move either. It lives in the Installer's own database, separate from the files it describes, so removing the app leaves `pkgutil` still reporting the package as installed. After a clean run of DisplayLink's official uninstaller, its two receipts were still there.

A password prompt in Finder is the other sign you are dealing with a package. The installer ran as root, so the bundle it left is owned by root, and moving it takes authentication. That is normal and is covered in [the uninstall troubleshooting guide](https://mole.fit/blog/mac-app-wont-uninstall).

## Check whether a package installed it

Start with the list of receipts and the app's own path:

```sh
pkgutil --pkgs | grep -i zoom
pkgutil --file-info /Applications/zoom.us.app
```

`pkgutil --pkgs` lists every package ID the Installer has recorded on the startup volume. Search for the vendor and the product name, not only the app's bundle identifier, because the two often have nothing in common. Zoom's app is `us.zoom.xos` and its receipt is `us.zoom.pkg.videomeeting`. The receipt that installs Cookie.app is `app.fantasticthing.Bookkeeping`. Even the case can differ: 爱思助手's bundle identifier is `cn.i4Tools.mac` and its receipt is `cn.i4tools.mac`, and `pkgutil` matches IDs exactly, so the mixed-case spelling answers "No receipt" while the receipt is sitting right there. Copy the ID from the `--pkgs` output rather than typing it.

`pkgutil --file-info` is supposed to name the package that installed a path, in `pkgid:` lines under the path. Do not read a missing answer as "not from a package". On macOS 27 I found it prints only `volume` and `path` for most paths, deleted or present; DisplayLink Manager's app got that empty answer while its two receipts were still on the Mac. A receipt is also not proof that you ran a `.pkg` yourself: the Mac App Store leaves one for some apps, such as `com.apple.pkg.TestFlight`.

## What a receipt records

Two commands show what one package installed and where:

```sh
pkgutil --pkg-info us.zoom.pkg.videomeeting
pkgutil --files us.zoom.pkg.videomeeting
```

`--pkg-info` prints the package ID, version, `volume`, `location` and install time. `--files` prints paths relative to that volume and location, so the real path is the three joined together. A receipt with location `Applications` lists `Foo.app/Contents/...`; one with an empty location lists `Applications/Foo.app/...` instead. Read the location before you read the list, or every path you look up will be wrong.

The list includes directories as well as files. `--only-files` and `--only-dirs` split the two, which is useful once you see that a receipt can list `Library` and `Library/LaunchAgents` themselves. The raw records sit in `/private/var/db/receipts` as a `.bom` and a `.plist` per package, but the `pkgutil` manual says the location of receipt files is subject to change and to always query them through `pkgutil`.

## A receipt is a map, not a delete list

It is tempting to feed `pkgutil --files` into a loop and remove everything. That is how a package uninstall breaks something else. The list says what this package wrote, not what only this package uses:

| What the list contains | Why you cannot just delete it |
| --- | --- |
| Directories such as `Applications`, `Library`, `Library/LaunchAgents` | The package created or touched them, but every other app on the Mac uses them too |
| Frameworks and helpers a vendor shares across apps | Word, Excel and PowerPoint all load Office's shared frameworks and crash at launch without them |
| Content several apps share | GarageBand, Logic Pro, MainStage and Final Cut Pro share `/Library/Application Support/GarageBand`, `/Library/Application Support/Logic` and `/Library/Audio/Apple Loops`, recorded under `com.apple.pkg.MAContent10_*` receipts |
| Another product the same installer brought | LogiRightSight came in with Logi Options+ and keeps working on its own |
| Launch agent and daemon plists | A loaded job has to be stopped before its plist goes, or launchd keeps a job with nothing on disk behind it |

The list also misses things. It records what the package's payload put on disk. Installer scripts can do more, and packages carry them: Foxit's, for example, has a postinstall script and an update service. The app writes its own data under your home Library once it runs, and none of that is in any receipt. For that side, use [finding leftovers after an uninstall](https://mole.fit/blog/how-to-remove-leftover-files-after-uninstalling-mac-apps).

## Run the vendor's uninstaller first

Apple's [guidance on deleting apps](https://support.apple.com/102610) is direct about this: if an app includes an uninstaller, "that's the best way to delete the app and any login items, extensions, or other data the app might have stored in other locations." Package-installed software often ships one, because the vendor knows its own scripts, helpers and shared parts. Look in the disk image the package came in, in the app's folder in Applications, in `/Applications/Utilities`, in the app's own menus, and on the vendor's support site. Splashtop Personal, for one, puts its uninstaller in the same disk image as the package.

If you already dragged the app to the Trash, put it back with **File › Put Back**, open it, and run its uninstaller from there. For security software, VPN clients and drivers the vendor's tool is not optional: extensions and network filters only come down through the app that owns them, which [uninstalling antivirus on Mac](https://mole.fit/blog/how-to-uninstall-antivirus-mac) covers.

## Removing it by hand

When there is no uninstaller, the receipt tells you where to look. Work from it in this order:

1. Quit the app and anything it runs in the background.
2. Read `--pkg-info` for the location, then `--files` for the list, and write down the paths outside the app bundle.
3. For each launch agent or daemon in the list, unload the job with `launchctl bootout` before moving its plist. [The launchd section of the troubleshooting guide](https://mole.fit/blog/mac-app-wont-uninstall) explains why the order matters.
4. Move to the Trash only what clearly belongs to this product: the app bundle, folders and plists named after its bundle identifier or product, its helper in `/Library/PrivilegedHelperTools`. Leave shared parent folders and anything the vendor's other apps still use. `pkgutil --pkgs | grep -i vendorname` shows whether other packages from the same vendor are still installed; if they are, their shared frameworks stay.
5. Forget the receipt last, once nothing it lists is left:

```sh
sudo pkgutil --forget com.vendor.pkg
```

`--forget` discards the receipt and, in the manual's words, does "not touch the installed files". Running it first leaves every file in place with no record pointing at them, which makes the rest of this job harder. It needs `sudo` because `/private/var/db/receipts` is owned by root, and it needs the ID exactly as `--pkgs` spells it. A stale receipt holds no user data, so if you are unsure whether something it lists is still in use, leaving the receipt costs nothing.

## Checking the result

These commands only read. Replace `com.vendor.pkg` and `vendorname` with what you found above:

```sh
id=com.vendor.pkg
loc=$(pkgutil --pkg-info "$id" | sed -n 's/^location: //p')
pkgutil --files "$id" --only-files | while IFS= read -r f; do
  p="/${loc:+$loc/}$f"
  [ -e "$p" ] && echo "$p"
done
pkgutil --pkgs | grep -i vendorname
ls /Library/LaunchAgents /Library/LaunchDaemons /Library/PrivilegedHelperTools | grep -i vendorname
launchctl list | grep -i vendorname
launchctl print system | grep -i vendorname
```

The loop prints every file from the receipt that still exists, with its full path. No output means the payload is gone and the receipt is safe to forget. Output inside the app bundle means the app is still installed; output elsewhere is what the removal missed, or what you decided to keep because another app shares it. If `pkgutil` answers "No receipt for ... found", the receipt is already forgotten or the ID is spelled differently. The `ls` and `launchctl` lines catch helpers the receipt never listed. `launchctl list` shows your own agents and `launchctl print system` shows the daemons. Any line from either means the job is still loaded, and a nonzero number in its first column means it is running now.

## How Mole handles pkg-installed apps

When you remove an app in [Mole](https://mole.fit/), it reads the receipts whose names match the app's bundle identifier or product name and lists the paths from them that still exist, but only inside a narrow set: the app bundle in Applications, and under `/Library` only the Application Support, Caches, Logs, PrivilegedHelperTools, WebKit and HTTPStorages folders, plus Preferences, LaunchAgents and LaunchDaemons plists, named with that exact bundle identifier. Those rows arrive unchecked, so you tick each one after reading it. Paths under `/Users`, `/opt`, `/usr` and `/private` never become rows from a receipt, and neither do the receipt files themselves.

After the app is gone, Mole forgets the receipt named after its bundle identifier, using the spelling `pkgutil` has on disk, and a vendor receipt it finds through `pkgutil --file-info`, the latter only when none of the files that receipt lists still exist. It does this only when the administrator helper was already authorized for that removal, so it never raises an extra password prompt for a receipt. The vendor lookup skips Apple's `com.apple.*` receipts.

The limit is the one described above. Because `pkgutil --file-info` rarely answers on macOS 27, a receipt whose ID has nothing to do with the app can stay after Mole removes it, as DisplayLink's two and Zoom's did. They are records only, and `sudo pkgutil --forget` clears them. For drivers, VPN clients and security software, Mole is not a substitute for the vendor's uninstaller.

## FAQ

### Does pkgutil --forget uninstall the app?

No. The manual says it discards all receipt data for the package but does not touch the installed files. Run it after the files are gone, never instead of removing them.

### Can I delete every file pkgutil --files lists?

No. The list includes system directories such as `Library` and `Applications`, frameworks the vendor's other apps load, and plists for jobs that may still be running. Use it to find what to review, then remove what belongs only to this product.

### The app is gone, but pkgutil --pkgs still lists it. Is it still installed?

Not necessarily. Deleting files never updates the receipt, so it stays until someone forgets it. Run the check loop above: if nothing the receipt lists still exists, only the record is left and `sudo pkgutil --forget` removes it.

---

Canonical HTML page: https://mole.fit/blog/how-to-uninstall-pkg-apps-mac
Blog index for agents: https://mole.fit/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt