What Is lsd on Mac? It Remembers 67 Apps That Are Gone

lsd is the Launch Services daemon. It keeps the database macOS uses to answer one question over and over: which app opens this file, this URL, this document type. It is not the drug, and it is not malware. On my Mac mini two copies of it have run for 28 days without a restart, together using 209 seconds of CPU. In the last 24 hours 2,613 different processes connected to it. And its database lists 447 apps, 67 of which no longer exist on disk.

Below: what the two lsd processes are, what they did in a day, why that app list keeps ghosts, and what still works on macOS 26 now that the old lsregister -kill reset is gone.

The rig is a headless Mac16,10 (M4) on macOS 26.4.1 (25E253), up 28 days. I measured everything on 2026-10-26 as an admin user, without sudo.

What lsd is

$ ps -axo pid,user,lstart,time,comm | grep '[/]lsd$'
  667 root      Mon Sep 28 11:47:48 2026   1:59.38 /usr/libexec/lsd
  864 sg-mini   Mon Sep 28 11:47:50 2026   1:29.81 /usr/libexec/lsd

$ launchctl print user/501/com.apple.lsd | grep -E 'runs|last exit|immediate'
	runs = 1
	immediate reason = ipc (mach)
	last exit code = (never exited)

There are two because there are two launchd jobs with the same label. /System/Library/LaunchDaemons/com.apple.lsd.plist starts the root copy with the argument runAsRoot. /System/Library/LaunchAgents/com.apple.lsd.plist starts one per user, in the Background session type, so it runs even with nobody at the screen. (LaunchAgent vs LaunchDaemon explains the split.) The root job registers 13 Mach services, the user job 11. The names describe the work: com.apple.lsd.mapdb (hand out the database), com.apple.lsd.modifydb (change it), com.apple.lsd.open and openurl, com.apple.lsd.trustedsignatures, and com.apple.security.translocation, the mechanism that runs a freshly downloaded app from a randomized read-only path.

The binary itself is tiny: 105,792 bytes, universal (x86_64 and arm64e). It links CoreServices, and the real code lives in LaunchServices.framework, version 1141.1 on this build. Its man page, dated 8/22/12, is two sentences long: lsd "provides various services for CoreServices frameworks. It is not meant to be invoked directly and it must not be terminated."

Load is low. The root copy used 119.38 seconds of CPU in 28 days 1 hour (0.0049% of one core, number 121 of 694 processes); the user copy used 89.81 seconds (number 130). The user copy's physical footprint was 6.4 MB, with a peak of 29.2 MB. Neither has a network socket.

lsd is not launchservicesd

Some explainers online treat the two names as one process. On this Mac they are separate: /System/Library/CoreServices/launchservicesd runs as pid 625, is ten times the size (1,126,704 bytes), and had used 4 minutes 34 seconds of CPU, more than both lsd copies combined. If Activity Monitor shows launchservicesd high, this article is about its neighbour, not it.

The database it guards

The user copy of lsd keeps one file mapped: /var/folders/…/0/com.apple.LaunchServices.dv/com.apple.LaunchServices-20971544-v2.csstore, 10,403,840 bytes. Apple's lsregister tool, buried at /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister, can print it. lsregister -dump took 1.94 seconds and wrote 19.7 MB of text. The header says the database was initialized on 2026-05-15 and has not been rebuilt since. Its record counts:

Record type	Count	What it is
type	4,756	Uniform type identifiers (public.json, com.adobe.pdf …)
claim	1,525	"This app can open that type" entries
plugin	554	App extensions
bundle	447	Apps and app-like bundles
extensionpoint	321	Places extensions can plug into
handlerpref	6	Defaults you (or an installer) chose

The six handler preferences are the whole of this machine's "Always Open With" history: Chrome for http, https, public.html and the default browser slot, set on 5/15, plus cmux and slack URL schemes, set by those apps on 9/28.

67 apps that aren't there

I took the path of every one of the 447 bundle records and checked whether it still exists. 67 don't (15%). Where they pointed:

• 35 on /Volumes/…: installer disk images that were mounted once and ejected. Chrome (7 records, counting helper apps), Orca (6), VS Code, Slack, Discord and Claude (5 each), cmux (2).
• 20 under my home folder, mostly inside ~/work probe directories this blog's research slots created and deleted: unpacked .pkg payloads, mounted images, even a __MACOSX/DashCamPlayer.app left over from a zip.
• 11 in /private/tmp, 1 in /opt/homebrew.

So lsd registers anything shaped like an app that passes through the file system, wherever it sits. That is also the cause in the clearest high-CPU report I found: in an Elixir Forum thread (2024), a developer's Mac kept freezing with /usr/libexec/lsd at 100% CPU. lsd was "trying to create signing signatures for hackney.app and mint.app", which are Erlang build outputs that happen to end in .app. Deleting the _build folders stopped it.

Why the ghosts stay

I built a do-nothing app, LsdProbe.app, that claims it can view JSON files, and asked macOS which apps open a .json file after each step. I used NSWorkspace.urlsForApplications(toOpen:), the same lookup behind the Finder's Open With list; the Mac is headless, so I couldn't screenshot the menu itself.

1. Registered copy A (lsregister -f, 0.014 s): it appeared in the JSON list.
2. Registered a second copy B with the same bundle ID: the list showed both. That is the classic "duplicate apps in Open With" bug, and it needs two copies that both exist.
3. Deleted copy A: it vanished from the list at once, and its record was gone from the dump too.
4. Put a third copy on a disk image, mounted it, registered it, then ejected it: it vanished from the list, but the record stayed in the database. Same pattern as the 35 /Volumes ghosts.

The practical news is good. Open With already filters out apps whose path is missing; none of the 67 ghosts showed up for .html (5 apps), .txt (6) or .json (4). Ghosts cost database space, not menu entries. If your Open With menu has duplicates, there really are two copies somewhere: an old one in ~/Downloads, on a still-mounted installer image, or inside a backup folder, for example.

What it did in 24 hours

I captured every log line from both lsd processes between 12:01 on 10/25 and 12:01 on 10/26 with /usr/bin/log show --last 24h --predicate 'process == "lsd"'. (In zsh, use the full path; log show explains why.) 7,228 lines: 6,650 from the user copy, 578 from root, 9 errors.

• Database handouts. 2,657 XPC connections from 2,613 distinct process IDs. 2,428 were to mapdb, the read path; 228 to modifydb. That is one new client every 33 seconds, around the clock, on a Mac nobody sits at.
• App installs. The busiest hour was 07:00 (907 lines). That's when this blog's morning slot unpacked Insta360 Studio for a compatibility test: 33 registration transactions for com.insta360.studio and its export and thumbnail helpers, and 28 records marked "will be registered launch-disabled".
• Failed check-ins. 443 times a process announced "registering self", and 439 times lsd answered Failed to register <private>: -10811. That code is kLSNotAnApplicationErr: the caller isn't an app bundle. They came from 225 short-lived processes, in bursts at 06:00 (124), 19:00 (94) and 03:00 (86). All had exited before I looked, and four candidates I tried (a Swift tool, osascript, swift, screencapture) didn't reproduce it, so I can't name the source. The error is noise, not a fault.
• Translocation cleanup. "SecTranslocate: attempting to cleanup unused translocation points" at 17:48, 23:48, 05:48 and 11:49, every six hours, alternating between the root and user copy.

Resetting it on macOS 26: -kill is gone

Most advice about lsd ends with lsregister -kill -r -domain local -domain system -domain user. On this Mac the help text no longer lists -kill, and the binary carries its own epitaph:

$ strings -a …/lsregister | grep -A1 '^-kill$'
-kill
# The -kill option has been removed because it was dangerous and no longer useful.

What remains is -delete, documented in the help as "Delete the Launch Services database file. You must then reboot!" An April 2026 Apple Community thread about Open With duplicates on Tahoe hit exactly this wall; the reply pointed to -delete plus a reboot, and nobody reported back. Howard Oakley's August 2026 guide warns that a deleted database fills up again "as soon as their folders are opened in the Finder". On a FileVault Mac a reboot also means typing the password at the machine, which is why I didn't run it here.

Two lighter tools did work in my test:

LSR=/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister

# compact the database (removed 81,920 bytes; kept every ghost)
$LSR -gc

# drop one record, even when the path no longer exists (rc 0)
$LSR -u /Volumes/LsdProbeVol/LsdProbe.app

# list ghost apps yourself
$LSR -dump | awk '/^bundle id:/{b=1} b&&/^path:/{sub(/^path: +/,"");sub(/ \(0x[0-9a-f]+\)$/,"");print;b=0}' \
  | while IFS= read -r p; do [ -e "$p" ] || echo "$p"; done

One caveat: Oakley found that -u "invariably returns an error" on Sequoia and Tahoe. I saw that once too. Pointed at an app on a mounted image that Spotlight wasn't indexing, it failed with -10814 from spotlight. Pointed at a ghost path or a normal folder, it worked.

When lsd uses high CPU

• Something keeps producing .app folders. Build outputs (Erlang/Elixir _build, Xcode DerivedData, Electron packagers), unzip loops, a sync tool. sudo lsof -p <lsd pid> | grep '\.app' shows what it's looking at.
• A crash loop. A 2015 El Capitan thread describes lsd running for seconds, dying with SIGBUS and restarting at 20 to 90% CPU; a database reset helped briefly and the thread closed unsolved. Check launchctl print user/$(id -u)/com.apple.lsd: on a healthy Mac runs stays at 1.
• Don't kill it as a fix. Both jobs are started on demand by their Mach services, so the next caller relaunches it, and on this Mac a new caller arrives every half minute. The man page says it "must not be terminated". It is in the same family as fseventsd and mds_stores: it reacts to file activity, so the cure is the thing producing the activity.

lsd also explains a pattern I found a day earlier. sharingd wrote its log in bursts of 92 lines, and every burst followed a LaunchServices.database change notification. Those notifications come from here.

FAQ

What is lsd on Mac?

lsd is the Launch Services daemon at /usr/libexec/lsd. It maintains the database that maps apps to the file types and URL schemes they can open, and serves it to every process that asks. macOS runs two copies, one as root and one per user, both started by launchd and restarted automatically.

Is it safe to quit lsd in Activity Monitor?

It won't break anything permanently, but it doesn't help. launchd starts lsd again as soon as any process needs Launch Services, which on a normal Mac is within seconds, and its man page says it must not be terminated. If lsd uses a lot of CPU, find what is creating or changing app bundles, such as build folders or repeated installs.

How do I fix duplicate apps in Open With on macOS Tahoe?

The old lsregister -kill command was removed. First look for a second real copy of the app, on a mounted disk image, in Downloads or in a backup folder, and delete or eject it. To remove one stale record, run lsregister -u with the app's path. lsregister -delete followed by a restart rebuilds the whole database.

Measured on 2026-10-26 on one headless Mac mini (Mac16,10, M4, macOS 26.4.1 build 25E253, up 28 days), as an admin user without sudo, so the root lsd's memory figure is missing. Process data come from ps, launchctl print, vmmap --summary and lsof; the launch configuration from the two com.apple.lsd.plist files; database counts from one lsregister -dump. Ghost paths were checked with a file-existence test on all 447 bundle records. The Open With tests used a test app registered and then unregistered with lsregister and NSWorkspace's urlsForApplications(toOpen:) lookup, not the Finder menu. The log figures come from one 24-hour /usr/bin/log show capture of the lsd process (7,228 lines), matched against this blog's own slot log. I did not run lsregister -delete, kill lsd or reboot, and I left the 67 ghost records in place. User reports come from one Elixir Forum thread and two Apple Community threads; the -kill and -u behaviour on Tahoe is cross-checked against Eclectic Light.