lsd high CPU on Mac? Launch Services, explained
lsd using high CPU on your Mac is the Launch Services database daemon: the registry of which app opens which file. Here's why it spikes, how to rebuild the database, and why it's not launchservicesd.
lsd is the Launch Services database daemon that keeps track of which app opens which file. When it spikes to high CPU, the cause is almost always a damaged or bloated Launch Services database, and the fix is to rebuild it. First, a naming point that trips up a lot of guides.
lsd is not "launchservicesd"
On modern macOS (Ventura, Sonoma, Sequoia and later), the process you'll see using CPU is lsd, at /usr/libexec/lsd. There's a separate, older daemon called launchservicesd at /System/Library/CoreServices/launchservicesd, a different process. Older articles that call the CPU-spiking Launch Services process "launchservicesd" are out of date. If you're on a recent macOS, you're looking at lsd.
What lsd does
Its man page says it "provides various services for CoreServices frameworks," and warns it "is not meant to be invoked directly and it must not be terminated." It maintains the Launch Services database: the registry of installed apps, their document-type and URL-scheme associations, and which app opens which file, including your "Open With" choices.
Why it's using high CPU
A damaged or bloated Launch Services database forces lsd to repeatedly re-read and re-verify registrations. Common triggers:
- Many apps installed, moved, or duplicated, including leftover app copies on mounted volumes or disk images.
- A bad registration, or an app that re-registers itself in a loop.
- Because modern macOS discovers apps via Spotlight, a Spotlight re-index can drive it too. If mds_stores is busy at the same time, that is not a coincidence: they are two ends of the same job, and the Spotlight side is usually the one to settle first.
The CPU is not always the worst of it. In documented Sonoma 14.1.1 cases lsd sat at 100% CPU, and in at least one it wrote hundreds of gigabytes to disk while doing so. If your free space has been falling for no reason you can name, that is worth knowing about: deleted files that don't free space covers the other reasons a disk shrinks on its own.
Is lsd a virus?
No. It's a legitimate Apple CoreServices daemon, and it must not be killed permanently. The high CPU is a symptom of a corrupt database or a misbehaving third-party app, not of lsd itself.
If you want to settle it rather than take our word for it, check the path rather than the name. Note the process's PID in Activity Monitor and run ps -o comm= -p <PID> in Terminal: the genuine one answers /usr/libexec/lsd, a folder System Integrity Protection keeps read-only. That test works for every background process on your Mac, and it is the first half of our guide to high CPU usage on a Mac.
What to do about it
- Rebuild the Launch Services database with
lsregister, then reboot:/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain system -domain user - If Spotlight is involved, rebuild its index too:
sudo mdutil -E /(see mdworker high CPU for the details). - Boot into Safe Mode, then restart normally. This clears many cases.
- Remove duplicate app copies, especially leftovers on external volumes or disk images.
Honest caveat: right after a rebuild your Mac is slower for a bit while the database repopulates; partly, you wait it out.
What a rebuild actually changes
The lsregister command above is not a repair in the sense of fixing one broken row. -kill -r throws the register away and builds a new one by re-scanning every app macOS can find. That has three consequences worth knowing before you run it:
- It takes a while, and the Mac is slower meanwhile. Every app has to be read and registered again. On a Mac with a lot of apps this is minutes, not seconds, and
lsdwill be busy for all of them — which looks exactly like the problem you were trying to fix. - Your "Open With" choices go back to the defaults. Those overrides live in the register you just discarded. Nothing is lost from disk; you simply have to tell macOS again that a
.txtfile should open in your editor rather than TextEdit. - It does not remove whatever caused it. If a third-party app re-registers itself in a loop, a fresh register gives it a clean surface to corrupt again. The rebuild buys you the time to notice which app that is.
What people get wrong
The common mistake is to force quit lsd, see the CPU drop, and treat that as the fix. It is not: macOS relaunches it within seconds, the register is still in the state that caused the spike, and in the meantime double-clicking a file can stop opening the right app. The same applies to almost every process in this family — see when force quitting a system process is and isn't the answer.
The second mistake is assuming lsd is acting alone. Launch Services is what Gatekeeper's syspolicyd consults to know an app has been registered, so an app that keeps re-registering can show up as two daemons busy at once rather than one.
See it settle after a rebuild
After rebuilding Launch Services you want to confirm lsd actually calms down rather than looping again. Plumby shows live CPU in your menu bar with the process named plainly, so you can watch it return to idle, or catch the app that keeps re-triggering it. Measured from your Mac's real state, never estimated.
