pkgutil –forget

What pkgutil --forget actually changes

pkgutil --forget removes a package receipt from macOS’s package database, so the system stops tracking that package as installed. It does not remove the files the package placed on disk, which means the software can still run even after the receipt is gone.

This distinction matters because package receipts are metadata, not the software itself. In practice, the command changes inventory and lifecycle state more than it changes the runtime footprint.

Package receipts versus installed files

On macOS, package management records what was installed through receipts, and those receipts help tools answer questions such as “what package put these files here?” and “is this package still present?” Forgetting the receipt breaks that bookkeeping link. The files, directories, launch items, or helper tools created by the package may remain intact unless they are removed separately.

That is why pkgutil --forget is best understood as a metadata operation. It can make a system look less managed than it really is, especially if administrators rely on the package database as their source of truth.

Why this command is used

Administrators usually use pkgutil --forget when they need to clean up an incorrect receipt, undo package tracking after a manual repair, or remove stale installer metadata that no longer reflects the machine state. It can also help when a package was installed partially or in a way that should no longer be represented in package inventory.

The command is not a replacement for uninstall logic. If a package supplies its own uninstaller, that is the safer way to remove both the tracked receipt and the installed components. If no uninstaller exists, receipt removal alone only changes what macOS believes is installed.

Operational consequences and verification

After a receipt is forgotten, the key question is whether the host still contains the package’s files, services, or helper processes. Operators should verify the actual filesystem state, because package metadata and on-disk reality can diverge. That matters for troubleshooting, software inventory, compliance checks, and incident response.

From a security perspective, a forgotten receipt can hide the fact that software remains present, which makes software inventory less reliable and can complicate exposure review. A package may still leave binaries, launch agents, or privileged components behind even though the package database no longer lists it.

Risk and Threat Considerations

Receipt removal can create blind spots when teams assume package records are equivalent to installed software. If the receipt is gone but the files remain, exposed components may persist without being visible in package-based inventory or change-control records.

Failure mechanism: The package database loses its record of the software while the installed files, services, or helpers remain available on disk, so defenders may miss a live exposure.

Impact: Asset inventory becomes inaccurate, cleanup can be incomplete, and residual software may continue to provide an attack surface after administrators believe it has been removed.

Practitioner Guidance

What to watch for: Treat pkgutil --forget as a bookkeeping change, not a full uninstall. Use it only when you have confirmed that the package’s files are already removed or that a separate cleanup process will handle them.

Governance implication: Keep package receipts, filesystem inspection, and endpoint inventory aligned so that software removal is validated against the real host state rather than the package database alone.

Related resources from NHI Mgmt Group

• What breaks when provisioning is treated as a fire-and-forget integration?
• What should teams do if an agent can forget its own policy?
• What breaks when organisations treat third-party integrations as set-and-forget access paths?
• What breaks when CTEM is treated like a set-it-and-forget-it solution?