Although macOS has been happily translocating apps since Sierra, nearly eight years ago, the process can still bring problems, particularly when an app appears to have cleared quarantine, and is run not infrequently. Any problems that can cause might appear odd: it may be slow to launch, never update, not work properly with software firewalls, and can even be unstable and crash. So how can you tell whether an app is running in translocation?

Where?

When an app is translocated by Gatekeeper, it isn’t moved, but copied in such a way that its files retain the same inode numbers, appearing on a different volume mounted in a randomised and hidden location, such as /private/var/folders/x4/[random chars]/T/AppTranslocation/[UUID]/d/. It only appears there while it’s running; the moment you quit that app, that location is unmounted, and vanishes. So there’s no point in looking at the app in its original location, as it will remain there all the time, and there’s no point searching for it when it’s no longer running.

While the app’s running, you can find it, as suggested by Quinn “The Eskimo!” of Apple’s Developer Technical Support, using
ps xw | grep AppName
in Terminal.

Once you know where to look, you could confirm that by looking in that path using the Finder.

Log records

There’s an easier way that you can use even if the app’s no longer running, provided you know the time that it was last launched, or you run it at a known time: inspect LaunchServices’ entries in the log. Fortunately that’s made easier by a ready-made log excerpt available in my free utility Mints, in its TCC Log Window.

Run the app at a known time, such as 11:05:00. Open Mints, and click on the TCC button at the top right of its window to open its TCC & Privacy log. Set the time there to app launch time (here 11:05:00) and the Period to 5 sec. Then uncheck all the boxes in the row below that, TCC, securityd and Other, leaving just LaunchServs ticked. Click on the Get log button, and a few moments later you’ll see LaunchServices’ log entries for that period, shown in red.

Scroll down through those entries and you’ll see messages such as
LAUNCH: Opening <private> with 0 items on behalf of 624 role=e flags=8000001 (null)
bundle 0x46fc is launch-disabled and needs to be set trusted

Then comes the answer:
LAUNCH: translocate to <private> from <private>
LAUNCH: Successful launched 0x0-0x81081 pid=2921 co.eclecticlight.Sparsity (quarantined) '<private>'
notifying server side, pid=2921 appInfo={ "ApplicationType"="Foreground", , "CFBundleExecutablePath"="/private/var/folders/x4/x00kny5x0_5dsnmmxhtw6hc80000gn/T/AppTranslocation/5D4920D1-5D63-466B-8C46-5E2F6790453A/d/Sparsity.app/Contents/MacOS/Sparsity", […] "LSLaunchBeforeTranslocationExecutablePathINo<…> […]

LaunchServices announces the translocation, and in several long messages gives you the full path to the translocation location. If the paths given contain the app’s regular location rather than a translocation path, then you know that app hasn’t been translocated after all.

Signs

There are also indirect signs that can lead you to suspect that translocation is occurring. Any software that relies on an app running from a stable and accessible path is likely to have problems. One example is Little Snitch, which associates its firewall rules with paths of apps and processes. It may therefore experience difficulties associating rules with an app being run in translocation, and report that.

Another situation where translocation can have noticeable effects is with apps using a self-updating mechanism, such as Sparkle. These may not be able to work if the app is in translocation, leaving the app running an older version than you’d expect.

Solution

If an app that appears to have been correctly installed is translocated, move it individually (one app at a time) from the folder it’s currently in to a different folder, and run it from there. That should clear it to run normally from anywhere that you want.