What Is corespotlightd on Mac? I Fed It 100,000 Items

corespotlightd is the macOS process that keeps the search index for content apps hand to Spotlight. Files on disk are indexed by a different set of processes (mds, mds_stores and the mdworker helpers). corespotlightd handles the other half: the messages, notes, contacts, bookmarks and documents an app describes through Apple's Core Spotlight API, and the searches that read them back.

On my Mac mini it had run for 26 days and used 23 minutes 9 seconds of CPU. That is 0.06% of one core, rank 51 of 686 processes. It had written 332.7 MB to disk in that time. Then I gave it 100,000 items of my own, searched them, deleted them and killed it, reading its counters at each step. Indexing 100,000 items cost 37 CPU seconds. Deleting them produced 1.27 GB of logical writes. Restarting it wrote 102 MB in under 15 seconds.

The rig is a Mac16,10 (M4, 16 GB) on macOS 26.4.1 (25E253), headless, with no Pages documents and no iCloud Drive. Everything below was measured on 2026-10-24 as an admin user without sudo.

What corespotlightd is

$ ps -axo pid,user,etime,time,rss,comm | grep [c]orespotlightd
  962 sg-mini  26-00:12:41  23:08.10 185984 .../Metadata.framework/Versions/A/Support/corespotlightd
82221 sg-mini  25-22:32:12   0:01.12   9408 .../Metadata.framework/Versions/A/Support/managedcorespotlightd

It runs as you, not as root. It is a per-user LaunchAgent (/System/Library/LaunchAgents/com.apple.corespotlightd.plist), which is why you can kill it without sudo. If the agent and daemon split is new, LaunchAgent vs LaunchDaemon covers it. The plist says a lot about what Apple expects from it:

• Mach services com.apple.spotlight.IndexAgent and com.apple.spotlight.SearchAgent. Going by the names, apps use the first to add or delete items and the second to search.
• Seven background tasks: a heartbeat every 2 hours, and daily jobs named duplicateOidCheck, expirations, reportAppUsage and reportStorageUsage (two of them in a second copy for protection class A, the encrypted indexes). A defrag job runs every 30 days.
• A jetsam memory limit of 4,000 MB. The plist allows it to grow to about 4 GB before the kernel kills it. Its peak on my Mac was 76.7 MB.
• A com.apple.corespotlightd.cachedelete service, so its index counts as space macOS can reclaim. I listed it among the CacheDelete clients in purgeable space on Mac.
• Two developer notifications, com.apple.corespotlight.developer.ReindexAllItems and ...ReindexAllItemsWithIdentifiers, which tell apps to rebuild their entries.

The index itself lives in ~/Library/Metadata/CoreSpotlight, one or more indexes per app, as Howard Oakley describes in Spotlight and Core Spotlight are different. I could not look inside it. The folder is mine and has ordinary drwxr-xr-x permissions, but from a shell without Full Disk Access every read fails:

$ ls ~/Library/Metadata/CoreSpotlight
ls: /Users/sg-mini/Library/Metadata/CoreSpotlight/: Operation not permitted
$ du -sh ~/Library/Metadata/CoreSpotlight
du: /Users/sg-mini/Library/Metadata/CoreSpotlight: Operation not permitted

That matters for the most common fix, below. If du prints this, the size check needs Finder or a terminal that has Full Disk Access.

What 100,000 items cost it

I wrote a 40-line Swift tool that uses CSSearchableIndex to add plain text items in batches of 500, to search them with CSSearchQuery, and to delete them all. It is an unsigned command-line binary with no app bundle, and corespotlightd accepted it anyway. Between steps I read corespotlightd's CPU time and disk counters with proc_pid_rusage, which works on your own processes without sudo. Each item had a title and a one-line description.

Step	Client wait	corespotlightd CPU	Physical writes	Logical writes
26 days of normal use (before the test)		1,389.1 s	332.7 MB	932.9 MB
Add 10,000 items	0.11 s	+3.5 s	+20.2 MB	+14.7 MB
Add 100,000 items (10,000 replaced)	7.71 s	+37.3 s	+96.2 MB	+582.9 MB
Search all 100,000	0.12 s	+0.13 s	0	0
Delete all items	6.52 s	+13.4 s	+18.8 MB	+1,273.2 MB
Kill it, let launchd restart it		3.4 s (new process)	101.8 MB	107.6 MB

Four things stood out.

The client returns before the work is done. Adding 10,000 items returned to my tool in 0.11 seconds. corespotlightd then worked for about 30 more seconds. The 100,000 run behaved the same way and was flat again within 60 seconds. An app that indexes in the background will show up in Activity Monitor as corespotlightd, not as itself.

Indexing cost about 0.37 ms of CPU and 1 KB of physical writes per item. 100,000 small items took 37 CPU seconds. For scale, that is 2.7% of everything the process had done in 26 days, spent in about a minute.

Deleting cost more than adding. Deleting everything took 13.4 CPU seconds and 1.27 GB of logical writes, more than twice the logical writes of adding 100,000 items. Most of it never reached the SSD as physical writes (18.8 MB did), and it was one call that held my tool for 6.5 seconds. Adding 100,000 items in 200 batches held it for 7.7.

The 32,767 limit did not apply. A 2024 Apple Developer Forums post says an app can index at most 32,767 items, and it has no replies. My search returned all 100,000. That is one client on one macOS version, so I would not build on either number, but on macOS 26.4.1 the cap is not 32,767.

The restart number needs a caveat. I killed the process about two minutes after the big delete, so some of those 102 MB may be cleanup of my own items rather than the normal cost of starting up. Either way, killing corespotlightd is not free. launchd had a new one running within 3 seconds (runs = 2, last exit code = 0), it read 108.6 MB and wrote 101.8 MB, and then it went quiet.

Two more things I checked. mdfind does not see Core Spotlight items: a search for the made-up word in every description found only my Swift source file. And corespotlightd's log mentions an IVFVectorIndex with "Shadow completed at vector count 49327", the same count before and after my test, so my plain text items were not added to it.

What it does on a normal day

Very little on this Mac. Its lifetime writes went from 265.2 MB on 2026-10-20 to 332.7 MB on 2026-10-24, about 18 MB a day. In 6 hours of logs it wrote 4,953 lines. 2,898 were search-request logging (client bundle: <private>, query nodes count N), and they bunched up when my scheduled jobs were running. Between 06:00 and 09:00, with nothing scheduled, there were 0 to 19 search lines per 10 minutes. During the 09:00 and 10:30 work slots it was 136 to 443. Another 414 lines were searches that failed with "no indexers are available", which happens when the index being searched does not exist on this Mac.

Apple redacts the client names, so I can't say which app sent each search. The pattern still answers the usual question. corespotlightd is busy when something on the Mac is adding to the index or searching it, and idle otherwise. It is the same on-demand pattern I found in suggestd, and the opposite of mds_stores, which reacts to file changes.

When corespotlightd uses high CPU

The reports I read are not about 0.06%. I read two Apple Community threads on corespotlightd from 2024 to 2026, 13 dated replies in "Continued corespotlightd process CPU overload issues" and the June 2026 Tahoe thread "Spotlight lagging issues on Tahoe anyone?". Three patterns repeat:

• CPU far above one core. Reported peaks were 400% on an M2 Ultra Mac Studio, "anything from 100% CPU all the way to 750%" across four Macs, and 100% to over 200% on M1, M2 and M4 Macs.
• A huge CoreSpotlight folder. Four posters gave a size before deleting it: 58 GB, 59 GB, 208 GB and 320 GB. A fifth, who scripted a deletion every two days, said problems started "north of 25 Gbs". After deletion the folder came back at 110 MB to 3 GB. Three of the four said the problem stopped, and the fourth was still watching.
• Pages documents, often in iCloud Drive. At least five posters tied it to Pages: large or heavily edited files, or files opened from iCloud Drive. One traced it to a single 32 MB Pages file, made a copy, deleted the original and reported corespotlightd at "POINT one percent".

One earlier report fits the write numbers above. On Hacker News in 2022, a user traced bursts of 150 MB/s writes, then a sustained 50 MB/s, to corespotlightd and suggestd indexing an RSS reader app.

Putting my test next to those reports: an app that keeps re-donating content (a document that changes on every edit, a feed reader that re-indexes every article) pays the add cost and the delete cost each time, and the index grows between defrags. Adding and deleting my 100,000 items cost about 115 MB of physical writes and 50 CPU seconds. Folders of 200 GB and CPU at several hundred percent are what that looks like after months.

What to do about it

1. Find the size first. Open ~/Library/Metadata/CoreSpotlight in Finder (Go > Go to Folder) and Get Info. In Terminal, du -sh only works if Terminal has Full Disk Access. A few hundred MB is normal. Tens of GB is the pattern above.
2. Look for the app. If you use Pages, close large documents and try moving the busiest one out of iCloud Drive, which helped several of the thread posters.
3. Rebuild the folder if it is huge. The approach the Lightqube post attributes to Apple Support: update macOS and Pages, rename the folder to CoreSpotlightOld, restart, then delete the old one. Apps lose their entries until they re-index them, which costs CPU and writes for a while, as the table shows.
4. Don't kill it on a loop. It comes back within seconds, and on my Mac one restart wrote 102 MB. Killing it hides the symptom and costs writes.

Turning off categories in Spotlight settings, or mdutil -i off, changes file indexing by mds. The Tahoe poster turned off Spotlight features and indexing and corespotlightd kept running. That matches the split above: corespotlightd serves apps, not the file index.

FAQ

What is corespotlightd on Mac?

corespotlightd is the per-user macOS process that keeps the Core Spotlight index: the messages, notes, documents and other content that apps add to Spotlight through Apple's Core Spotlight API, plus the searches against it. It runs as a LaunchAgent under your account and stores its data in ~/Library/Metadata/CoreSpotlight. Files on disk are indexed separately by mds and mds_stores. On a Mac mini that had been up 26 days it used about 0.06% of one CPU core.

Why is corespotlightd using so much CPU?

Usually because an app is adding or deleting a lot of content in the index, or the index has grown very large. Apple Community reports most often point to large or heavily edited Pages documents, often stored in iCloud Drive, with CoreSpotlight folders of 58 GB to 320 GB. In a test, adding 100,000 small items cost corespotlightd 37 CPU seconds, and deleting them cost another 13 seconds and 1.27 GB of logical writes.

Can I delete the CoreSpotlight folder?

Users report that deleting or renaming ~/Library/Metadata/CoreSpotlight and restarting fixes runaway corespotlightd, and that the folder rebuilds at 110 MB to 3 GB. It is not documented by Apple. Apps lose their Spotlight entries until they re-index, so search results from those apps will be incomplete for a while. Terminal needs Full Disk Access to read the folder, so check its size in Finder first.

Measurements come from one Mac16,10 on macOS 26.4.1, read without sudo on 2026-10-24: the launchd plist and launchctl print, ps CPU totals for 686 processes, proc_pid_rusage counters for corespotlightd before and after each step of a CSSearchableIndex test with my own throwaway items (all deleted afterwards, and the search returned 0), one killall corespotlightd, and 6 hours of log show --process corespotlightd. The 2026-10-20 write figure is from my earlier suggestd measurement on the same process. I could not read the index folder or its size (TCC), so I have no folder size of my own to compare. The CPU, folder size and Pages reports are user posts in two Apple Community threads and one Hacker News comment, not my measurements. The restart figure was taken right after a large delete and may include its cleanup.