In this article
This works with macOS Installer receipts. It is a different question from finding every file an application has created since you first opened it. Start by identifying how the software reached your Mac: through a PKG installer, by dragging an app from a disk image, or through another package manager.
Choose the evidence that matches your question
| Question | First check | Limit |
|---|---|---|
| Which paths did a recorded PKG install? | pkgutil --files | Receipt paths may differ from today's files |
| What is the path relative to? | pkgutil --pkg-info | Do not assume every install location is / |
| Which receipt mentions this file? | pkgutil --file-info | A result is not exclusive ownership |
| What will a downloaded installer do? | Inspect the original package and scripts | An old receipt cannot reconstruct every installer detail |
| What did an app create after launch? | Current app data and saved comparisons | A payload list is not a lifetime activity log |
The Apple manual installed on your Mac, available with man pkgutil, documents the receipt commands. Prefer that interface over depending on a particular receipt-folder layout. macOS can change where it stores those records.
Find the identifier before listing files
Open Terminal and run /usr/sbin/pkgutil --pkgs. The output contains package identifiers. Find the entry associated with the vendor or component you want to inspect, and copy its exact identifier.
An identifier such as com.apple.pkg.CLTools_Executables is not an installer filename. Passing a downloaded filename ending in .pkg to a receipt query is not the same as identifying the installed record. Some products have several component packages, so one plausible-looking match may cover only part of the installation.
For a selected identifier, run these read-only queries:
pkgutil --pkg-info PACKAGE_ID— inspect the version, volume and installation location.pkgutil --files PACKAGE_ID— list the recorded paths.pkgutil --only-files --files PACKAGE_ID— narrow the listing to files when directory entries are distracting.
Replace PACKAGE_ID with the exact value you found. These queries do not install or uninstall software. If a query reports no receipt, recheck the identifier and installation method instead of treating the result as proof that the app left no files.
Armin Briegel's package-inspection walkthrough explains the important path rule: the listing is relative to the package's installation location, which is commonly, but not always, the filesystem root. Resolve that context before looking up a path in Finder.
A real receipt contains more than app files
On September 24, 2026, we queried com.apple.pkg.CLTools_Executables on macOS 15.7.5. Its receipt reported version 16.4.0.0.1.1747106510, volume /, and installation location /. The listing contained 4,646 entries, including directories.
We then separately checked three recorded paths against the current filesystem:
Recorded path, relative to / | Present in receipt | Current observation |
|---|---|---|
Library | Yes | /Library exists as a directory |
Library/Developer/CommandLineTools/usr/bin/git | Yes | The resolved file exists |
Library/Developer/CommandLineTools/usr/bin/clang | Yes | The resolved file exists |
This small sample shows why interpretation matters. /Library appears because it is part of the installation hierarchy. That does not make the whole directory a disposable component of Command Line Tools.
The test established receipt membership and current existence for those three paths. It did not verify every entry, compare file hashes, prove exclusive ownership, or uninstall anything. The receipt's version is the version recorded for that package; it is not a guarantee about every executable currently at those locations.
Use a reverse lookup for one known file
If you already have a full path, pkgutil --file-info /full/path/to/file asks the receipt database about that location. This can be useful when a helper or command-line executable is unfamiliar and its filename does not identify the installer clearly.
Keep the reported package identifier with the path in your notes. Several packages can mention the same location. An installer update, a later replacement, or a shared directory can make the relationship more complicated than “this app owns everything under this folder.”
For a background component, follow the file identification with a separate check of startup settings and running services. A file on disk, a configured startup item and a running process are different observations.
Know what the receipt leaves out
Installer scripts can perform work beyond unpacking a payload. Applications can also create settings, caches and documents later. A drag-and-drop app may have no corresponding Installer receipt at all.
For a graphical look at an original PKG, the vendor's Suspicious Package user guide describes an All Files view and separate inspection of installation scripts. Its receipt support has limits: a receipt is not a retained copy of the entire installer. That makes the original package useful when the question concerns scripts rather than just recorded file paths.
Do not use pkgutil --forget as an uninstall command. Apple's local manual describes it as removing receipt information without touching installed files. Forgetting the record therefore cannot establish that the software has been removed, and it throws away evidence you may still need.
When removal is the goal, check the vendor's current uninstall instructions before acting on a path list. Do not pipe an unreviewed receipt into a deletion command.
Connect a record to the installed app
VaultDog's application passport can associate installer-record identifiers and common related locations with an installed application when matching evidence is available. This helps organize the next inspection, especially when files and background components are spread across several places.
Use the first-scan walkthrough to understand that workflow. A name or identifier match still needs context; VaultDog does not turn a receipt into a complete ownership manifest or guarantee that a related item is safe to remove. Use pkgutil when you need to inspect the receipt's path listing directly.
Keep a short inspection record
Before drawing a conclusion, save the exact package ID, recorded version, volume, installation location and date of your check. For each interesting path, note whether it was merely listed or separately found on disk.
Then choose the next step from the question: inspect the original installer for scripts, inspect current app data for later changes, or use the vendor's removal procedure. The useful result is a traceable explanation of a file's possible origin, with the remaining uncertainty still visible.
