Most everyday problems with LaunchServices should be fixed using the GUI. For those that can’t, two command tools, lsregister and lsappinfo, are available to help. This article explains what they can and can’t do for macOS Sequoia and Tahoe.

lsregister

This command tool is hidden away in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister, and typing that in with the -h option will show its usage information, the closest it gets to documentation. If you’re going to use it much, you’ll want to create an alias for it, or add it to your PATH with
PATH=/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support:"$PATH"
to use the command as lsregister, as I’ll do here.

Useful lsregister commands follow one of two forms:
lsregister [options] [path]
to register or unregister an item (usually an app) specified by the path, and
lsregister [options] [-apps domainlist] [-libs domainlist] [-all domainlist]
to act on the LaunchServices database for the given types (apps, libs, all) and domains. Domains are usually specified as a list of letters:
u,s,l,n
is the complete set, covering user (your Home folder), system, local and network.

App registration

In the past, apps used to populate the LaunchServices registry were those located in the conventional Applications folders, but recent versions of macOS have extended that to cover almost any accessible folder. It was Jeff Johnson who first showed that excluding folders and volumes from Spotlight indexing, by adding them to the list in Search Privacy… in Spotlight settings, excludes those apps from LaunchServices’ list. You can instead hide the folder they’re in by adding a dot to the start of its name, although that fails if you open that excluded location in the Finder.

You can try to remove an app from the LaunchServices registry using the command
lsregister -R -f -u pathname
where pathname is the path and name of the app. In Sequoia and Tahoe, that invariably returns an error that lsregister “failed to scan [path]: -10814 from spotlight,” where the path given is that to the app. That error code comes from LaunchServices, and its name reveals the cause: kLSApplicationNotFoundErr, even when the pathname given to lsregister is correct. Despite that error, if that app is hidden from Spotlight search, this should prove effective until it comes undone again.

This over-enthusiasm to register apps can be worse than a nuisance when running a lightweight macOS Virtual Machine on Apple silicon. If you make the host’s Applications folder a shared folder with the VM, then open that in the VM, all the apps within it are promptly added to the Open With… list in the guest, a behaviour likely to be unwanted.

Dump the registry

lsregister -dump > filepath
dumps the entire contents of the LaunchServices registry to filepath in many MB of text. Although this can be helpful when trying to fix a problem with LaunchServices, such as discovering conflicts in UTIs and filename extensions, the sheer quantity of text is overwhelming.

Reset the registry

In the past, one last-ditch method of addressing LaunchServices problems has been to reset its registry using the -kill option, but that has now been removed from Tahoe. As it tended to cause havoc, this is no great loss. The one remaining destructive command is
lsregister -delete
which must be followed by restarting, as it deletes LaunchServices’ database file, which must then be recreated, just as when first configuring macOS. Although that does initially remove all those unwanted stray apps, as soon as their folders are opened in the Finder, they’re added back.

lsappinfo

In contrast, lsappinfo is documented in its man page, which is extensive and fairly accurate, and by usage info in response to the command
lsappinfo -h
which is exhaustive and voluminous.

The starting point for exploring this command is
lsappinfo list
which is probably best piped into a text file for easy browsing. This lists all running apps and processes known to LaunchServices, and gives a brief summary of what it knows about them. If you want full details on everything running, then pipe
lsappinfo -all list
to a text file, as that tells you pretty well everything LaunchServices knows about apps and processes. Unlike lsregister -dump, lsappinfo only sees apps and processes that are currently running, and its text output is in JSON format.

This tool is most useful for giving information about just one running app or process. To do that, use
lsappinfo -all info "TextEdit"
to show all the information about TextEdit. You can specify the app using its ASN if you prefer, such as in
lsappinfo info ASN:0x0-0x34034:
or give its bundle ID:
lsappinfo info "com.adobe.AdobeResourceSynchronizer".

In addition to delivering information, there are four other valuable verbs:

• listen, which reports LaunchServices events such as apps being started or brought to the front;
• launch, which launches an app or process specified by its path;
• restart, which restarts the launchservicesd service at the heart of LaunchServices, and requires elevated privileges using sudo;
• log, which sets LaunchServices to write more or less entries in the Unified log.

Unfortunately, neither lsregister nor lsappinfo offers any direct solutions for problems with LaunchServices, although the information they provide can be helpful if you’re prepared to wade through it.