In this article
A crash report or Activity Monitor entry might show a long path under /private/var/folders/ even though you can see the app in Downloads or Applications. That discrepancy deserves a closer look. The path alone does not establish that a second app was installed, that the app is malicious, or that its visible copy has moved.
What the unusual path actually explains
Apple calls the feature Gatekeeper path randomization. Its platform security guide explains that Gatekeeper can open an app from a randomized, read-only location to prevent it from automatically loading malicious plug-ins distributed alongside it.
The important boundary is between the app's visible installation location and the location used by a running instance. A familiar app name inside a random directory can be consistent with that mechanism.
An illustrative path shape is:
/private/var/folders/…/T/AppTranslocation/…/d/Example.app/Contents/MacOS/Example
The ellipses and Example name are placeholders, not output from a test on your Mac. Look for the complete path belonging to the executable you are investigating. Merely finding the word AppTranslocation in a log, document, or unrelated open file is weaker evidence.
Apple's Developer Technical Support notes also set a limit: the exact conditions that trigger translocation are undocumented and have changed. Do not turn an old checklist about download format, signing, or folder location into an absolute rule for every macOS release.
Inspect the running instance before moving anything
Open Activity Monitor, find the app, and double-click its process to inspect it. In Open Files and Ports, look for the app's executable path, including the app bundle and its Contents/MacOS component. Keyboard Maestro's own translocation troubleshooting guide documents this inspection method.
If you see several similarly named processes, identify the main app and note its PID. A helper's path answers a question about that helper. It should not automatically stand in for the main app's path.
For a focused Terminal check, use the PID you just identified:
ps -p 12345 -o pid=,comm=
Replace 12345 with that current PID. This is a read-only process query. If the process has already exited, find the running instance again. A PID is temporary and should not be saved as the app's identity.
Keep the visible app location and the running path in separate fields. Searching Finder for an old random path after the app has quit is not a reliable way to identify the copy you launched.
Use a before-and-after evidence sheet
The following worksheet is an original diagnostic aid, not a claim that every installation will produce the same transition.
| Record | Before installation or relaunch | After opening the intended copy |
|---|---|---|
| App identity | Name, version, and bundle identifier if available | Confirm that you are comparing the intended app and version |
| Visible copy | The app you selected in Finder | Its intended installed location |
| Running instance | Current PID and full executable path | New current PID and full executable path |
| Symptom | The exact update, launch, or missing-resource error | Whether that same action now succeeds |
A changed PID alone proves very little: a new process normally receives a new identifier. A changed executable path is the relevant location evidence. A successful update or launch is separate evidence about the symptom.
If the app now runs from its intended installation location but still fails, stop treating the failure as automatically caused by translocation. Preserve both observations. This avoids a diagnostic loop in which every subsequent error is blamed on the first unusual path.
Follow the normal Finder installation route
For a drag-and-drop download, save your work and quit the running app. Use Finder to place the app in the location specified by its developer, commonly Applications, then open that installed copy. If the download is a package installer or has special instructions, follow that installation process instead.
Apple's File Provider translocation documentation recommends dragging the app to its intended installation location before launching it. That page addresses a specific extension error; it supports the installation step, not a guarantee that moving any app will repair every failure.
The source of the download matters too. If you cannot establish which copy came from the developer, get the current installer from the developer's official site. Avoid replacing an existing copy blindly when it might contain a different version you still need.
Once the installed copy works, the separate DMG cleanup guide explains when the disk image is just installation media. Deleting a DMG and diagnosing a running path are different tasks.
Why moving the app can help a real symptom
Some apps expect resources beside their bundle, or try to replace their own files during an update. A randomized read-only runtime location can interfere with those assumptions.
PaperCut documents a concrete client-installation error involving a path under AppTranslocation and recommends copying its client to Applications before running it. That vendor-specific example is more useful than assuming that every slow launch or failed update has the same cause.
Apple's developer notes recommend packaging resources so an app can work even when translocated. They also say there is no supported general-purpose way for an app to recover its original, untranslocated path. A visible diagnostic clue is not a stable API contract.
Keep location separate from a trust verdict
Do not delete random folders under /private/var/folders to “clean” the condition. The normal installation and relaunch check provides a clearer next step. Removing quarantine attributes or disabling Gatekeeper is also unnecessary for this diagnostic workflow.
If the path remains unexpected, send the developer the app version, macOS version, intended installed location, current executable path, and exact failing action. Remove private usernames or unrelated file paths before sharing the record.
For identity questions, find the app's bundle identifier. For signing questions, check the code signature separately. Neither an ordinary Applications path nor a valid signature is a complete safety verdict; each contributes one specific piece of evidence.
