Continued corespotlightd process CPU overload issues

Okay, I have a new hypothesis as to what's going on here with corespotlightd. This process is one of at least four that are responsible for macOS's Spotlight functionality. The three others are mds, mdworker, and md_stores. I cribbed the following descriptions of these three processes from the HowToGeek website:

The two processes [mds and mdworker] are part of Spotlight, the macOS search tool. The first, mds, stands for metadata server. This process manages the index used to give you quick search results. The second, mdworker, stands for metadata server worker. This does the hard work of actually indexing your files to make that quick searching possible.

And for md_stores, from the TechNewsToday site:

Mds_stores is the core indexing process of the macOS. On normal days, it usually takes up a noticeable [sic, probably should be un-noticeable] amount of CPU. However, when you reinstall your OS or add new files/directories, your system will automatically start to reindex these new databases, which sees the mds_stores CPU usage skyrocket.

The macOS Spotlight feature makes use of two processes for indexing the system database; mds and mds_stores. The mds (Metadata Server) process is responsible for tracking and recording files and folders in your operating system. md_stores then compiles and manages these mds metadata, which Spotlight later uses for searching certain documents within your OS.

So it may be that corespotlightd is in fact an unwitting victim of other processes' having gone awry. On my two Intel systems, by three months after installing macOS 15.0, metadata associated with Spotlight located at ~/library/metadata had reached half a terabyte on both systems. It sounds like this data was actually written out by either mdworker, mds_stores, or both. And then, corespotlightd has to wade through these gigabytes upon gigabytes of metadata to actually produce search results, and as that task gets harder and harder with more and more metadata being produced, eventually Spotlight search results (which includes search and smart folders through Mail) degrade to the point of uselessness.

While I haven't managed to halt the rapid growth of metadata on these two Intel systems (Apple Silicon Macs still have the issue but to a much milder degree), simply deleting the metadata out of the ~/library/metadata/Corespotlight and ~/library/metadata/SpotlightKnowledgeEvents (while leaving the folders themselves intact) resulted in a near-immediate improvement in three areas: greatly reduced use of storage space; vastly improved search results; and much lower processor utilization by corespotlightd.

As noted, this metadata still continues to pile up (especially if I have a large (>5 MB) Pages file open). But if I have to empty out these two folders once every few weeks until Apple resolves the issue, that's not the end of the world).

luzggg wrote:

Currently trying this out to fix that bug myself, and I have absolutely no idea what I'm doing. So I just want to make extra sure I got what you're saying. Now when you said deleting the metadata out of Corespotlight and SpotlightKnowledgeEvents, can I just delete everything inside those folders? Not working with Terminal here. Or keep the folders inside intact and just delete the lists and whatever is in there? Thanks!

When I spoke to Apple Support last week, the advisor suggested I delete the contents of the two folders (the entire contents, files and any subfolders; you don't need to go through each subfolder and laboriously delete its contents individually), but not the folders themselves. You don't need to do this from Terminal; you can just trash the files/subfolders from the Finder the way you would normally do it (just make sure you're in the User library, not the System library, which you can make visible on the "Go" menu in the Finder by holding down the Option key).

Other users have said they've been successful deleting the entire folders, contents and all, without ill effects. But having removed the folder contents themselves without deleting the actual folders, I've obtained satisfactory results all three times I've done it, on two different systems (twice on one of them).

Also note that the folder structure in the ~/library/metadata/ folder differs from Intel systems compared to Apple Silicon systems. On Intel systems, the CoreSpotlight/ folder and the SpotlightKnowledgeEvents/ folder are both at the root of the Metadata/ folder. On Apple Silicon systems, the SpotlightKnowledgeEvents/ folder is inside the CoreSpotlight folder. I have yet to try this fix on an Apple Silicon system since it hasn't been necessary for me, but it sounds like you can delete the entire contents of the CoreSpotlight/ folder without any problems.

Hi everyone. I also encountered this issue that corespotlightd was slugging down my M1 MBP 16GB (2021) so immensely that my system had a freeze for around 5-8 seconds every minute or so.

Reading that according to your findings it might be related to large Pages files it got my attention because I'm currently working on my Thesis and use Zotero with lots of indexing and caching. I assumed this might be the limit of this machine but that thought was strange because I worked on so much more taxing tasks and it just performed good enough that the operating system was still performant enough. My Thesis file currently only has half a MB (currently mainly text) so that can't be the issue I thought.

After working for days like this (it really gets frustrating) I decided to invest some time in troubleshooting again. Before that I tried to reindex Spotlight (through System Settings and Terminal) or cleared up some space but nothing did the trick. Also not even turning off Apple Intelligence which I thought could be the culprit made a difference. Until I stumbled upon some thread somewhere which just generally stated that deleting the Cache Folder in Library (Finder>Go>Go To Folder>~/Library/Caches) might help or not but it's generally not a bad idea to clean it out from time to time. Well I didn't do that for like 4 years! Which actually speaks for the rigidity of macOS.

I went to that folder and it had a size about 50GB and literally right after deleting it the freezes and the high CPU usage of corespotlightd went away. I now waited several hours to see if it was just something temporary but it seems like this was indeed the solution.

And I forgot to mention: I upgraded from 15.2 to 15.3 several days ago and it seems like something in the Cache became corrupted or faulty (be it system files or app files) and caused corespotlightd to go rampant.

So in short: give the cleanup of the ~/Library/Caches folder a try. It might help and solve this high CPU usage of corespotlightd. Hope this helps anyone.

AshkaTheMoltenFury wrote:

So in short: give the cleanup of the ~/Library/Caches folder a try. It might help and solve this high CPU usage of corespotlightd. Hope this helps anyone.

Unfortunately, I think that apple's default to "sort by rank" means that many people are MISSING the most important discoveries in this thread. The above WILL make things better, but only temporarily – it's treating the symptom, not the cause.

The cause of all this, as ericmurphy has laid out and a number of us have replicated, has to do with a problem with spotlight indexing of Pages files. Even if you clean everything out, as above, if you then open Pages files (especially larger ones) and keep them open, you can literally watch as the various mdworker processes write MASSIVE amounts of data into the core spotlight metadata folders. Depending on other aspects of your system, at some point that folder will get so big that the corespotlightd process will slow your Mac down.

• The temporary workaround is to regularly delete the metadata folders.
• The temporary and still very much less than ideal "fix" is to TURN OFF spotlight indexing.
• Any real solution here will require Apple to make some tweak to spotlight or Pages.

After the better part of another day thinking about and troubleshooting this issue, I am convinced that Eric Murphy's earlier hypothesis is correct. There's a bug in Sequoia, which anyone can replicate by following these 2 steps:

1. Open a Pages file (and keep it open).
2. Watch the size of this folder balloon: ~/Library/Metadata/Corespotlight

The larger that folder gets, the more likely it is that the corespotlightd process will start taking over the CPU and causing slowdowns for the Mac user. The corespotlightd process is what gets most people's attention, but it's only a symptom of the underlying problem whereby the spotlight processes (mdworker, etc.) write enormous amounts of data into the corespotlight subfolders.

The bigger the Pages file the quicker the folder grows in size; the more frequently one uses Pages, or leaves Pages files open, the worse the problem.

There is no fix until apple implements one, and the only viable workaround is to monitor the size of that folder and occasionally delete it.

One silver lining: it's not clear to me that there is any need to delete your spotlight index, to turn indexing off and on, etc. The problem stems from the size of that metadata folder, and you can alleviate the problem by deleting the folder. In my experience (having deleted the folder many dozen times), spotlight works just fine without rebooting, reindexing, or anything else.

I came up with my own way of dealing with this issue: I wrote a simple shell script that trashes the corespotlightfolder; then I added that as a service in launchd so that it can run regularly (maybe every 2 days).

Update: Running 15.3 on a 2022 M2 MacBook Air. I followed others and trashed the entire ~/Library/Metadata/CoreSpotlight folder 3 days ago on 2/10/25. Since then I only turn on Pages when I use it - which I have continued to do so. I also, split off some subtopics into their own documents so I wasn't having very large graphics heavy files open and editing all over the place in different sections. I do continue to save frequently- an old habit. My CoreSpotlight folder reappeared right away and the computer problems ceased. The folder is currently at 2.4 Gb compare to over 58 Gb when it was having difficulty. I have only 8 Gb of Memory if that matters. We did try one additional step before trashing CoreSpotlight. We turned OFF that process in the Activity Monitor. That seemed to cause a slight decrease in the folder size ~50Gb. But the effect was temporary of course as the process restarted.

Thanks to everyone - I hope Apple takes notice.

I’ve been troubleshooting a recurring issue with corespotlightd (CPS) spiking CPU usage — often over 200% — when using Pages. It renders my otherwise fast, brand-new M4 MacBook Air nearly unusable.

I’m trying to determine if this is:

• Processor or Mac model specific

• Related specifically to iCloud Drive

1. Is CPS Processor or Mac-Specific?

I never experienced this issue on my MacBook Pro M1 Max, running Sequoia or earlier versions (Monterey, Ventura, Sonoma). Since March 13, 2025, I’ve used my M4 MacBook Air for all my daily writing in Pages — and this is where CPS began.

Has anyone else seen corespotlightd spikes on an M1 Max MacBook Pro? That would help rule out a hardware-specific trigger.

2. Is CPS iCloud Drive Dependent?

In my experience: yes.

Here’s what I did:

• My last major CPS spike occurred even after quitting Pages for over two days.

• I reinstalled Sequoia 15.5, and after file indexing completed, CPS calmed down.

• Before reopening Pages, I duplicated all my current Pages documents and placed them in a local folder:

Macintosh HD > Users > [MyName] > InProgressNoCloud

• iCloud Drive is still active, with Optimize Mac Storage ON.

For three days now:

• I’ve been editing these local Pages files, keeping them open alongside other apps like Mail, Messages, and large Numbers spreadsheets (still stored in iCloud).

• There have been no corespotlightd spikes.

• In fact, the corespotlightd process doesn’t appear at all in Activity Monitor when working outside of iCloud.

• In contrast, with Pages files stored in iCloud/Documents or iCloud/Desktop, corespotlightd is always active.

This suggests a strong link between Pages auto-saving to iCloud Drive and Spotlight re-indexing, which seems to trigger runaway CPS activity.

A Temporary Solution

So far, keeping active Pages files out of iCloud Drive and stored locally appears to solve the problem.

But this isn’t ideal:

• I rely on my 2TB iCloud Drive to sync and protect files — I don’t want to back up Pages manually.

• I prefer not to split screen space with Activity Monitor just to monitor CPU usage.

• Most importantly, I want confidence that my M4 MBA won’t grind to a halt mid-session due to runaway corespotlightd.

As a side note: I do use SuperDuper to back up my MBP (for Logic Pro files, which must be stored locally), but for documents, iCloud Drive has been excellent — until this. Another side note: I've had two other process spike issues and BOTH were triggered by Pages: mdworker in 2013 and AppleSpell in 2019.

Next Steps

I’ll continue testing my temporary solution and will update this post immediately if CPS returns.

It’s been a week since my last post (about corespotlightd spiking with Pages v14.4 documents open) on my M4 MacBook Air (Sequoia 15.5), and my temporary solution.

That temporary solution - opening all Pages documents from local (not iCloud) folders - continues to work successfully after more than a week: that is, corespotlightd has NOT spiked at all.

I can add some more colour:  with Activity Monitor open (with the corespotlightd process permanently tracked):

working on my numerous, (very large) local Pages documents, corespotlightd is inactive (i.e. 0%.);

if I then open very large Numbers files that ARE located in iCloud (iCloud/Documents), the corespotlightd process begins but does not spike. If I leave these Numbers documents in iCloud open in the background, corespotlightd ticks over at 0.2%.

So for me, on my M4 MacBookAir (Sequoia 15.5, Pages 14.4)  I have a repeatable, persistent, demonstrable bug:

Pages documents located in iCloud/Documents: starts the corespotlightd process which then spikes @ >100% (and only a Sequoia reinstall stops the process);

Pages documents located in local SSD: corespotlightd = 0%

More colour: As I have mentioned previously, Pages has form in process spiking: mdworker in 2013 and AppleSpell in 2019.

If others on this thread experience corespotlightd spiking under different circumstances, there may be more than one issue . . . but as I say, my particular issue is repeatable, demonstrable and [at least after one week] avoidable through a [hopefully] temporary workaround.

I hope Apple is working on this issue. (Pages was last updated to 14.4 on April 3, 2025.)

For me, too, the issue clearly appears to be related to iCloud. I already have an automator process in place that deletes the spotlight metadata folder every single day, but even that does not alleviate the problem altogether. After a few hours with Pages documents open, the system starts to freeze up, and corespotlightd runs at over 100% CPU. Even deleting the metadata folder every day, it quickly grows to over 50GB.

Hearing from your experiences, I took the Pages files that I am working on out of iCloud. So far, after several days of working this way, the problem is non-existent. Corespotlightd does not even appear in Activity Monitor. However, as soon as I open a pages document in iCloud and start to make some edits, within a minute or so corespotlightd appears at the top again.

For reference, I'm working on an M2 Macbook Air.

I totally understand your frustration regarding Pages corespotlightd spiking. The lack of response from Apple is unusual: 

Back in 2013 and again in 2019, Pages was causing process spiking for mdworker and AppleSpell respectively. 

In both cases, I reported issues via Apple’s Feedback Web pages and was contacted by Apple, asked to install profiles, emailed the files back to Apple, and the issues were fixed. 

I posted a temporary Pages corespotlightd solution a month ago - do not use Pages with iCloud Drive - and it it is still effective. In case you have not seen that post:

Move any extant Pages files you want to open on your local SSD (i.e. not in iCloud Drive) before you open them.  When you create a new Pages file, immediately save it to your local SSD.

This works because if your Pages files lives in iCloud Drive, Pages triggers  corespotlightd   . . . which then spikes to > 200% and slows down your Mac  to the point of un-useability even after Pages is quit. (When corespotlightd is spiking, the only way to stop it, is to reinstall MacOS.)

I have the base variant of the Apple Mac Mini with M4 SoC (16GB RAM + 256GB storage).

About three days ago, I installed macOS Tahoe 26.0 (stable). A few hours later, I received a notification that my Mac is low on storage. When I went to the desktop to check free space on Macintosh HD, I saw that it was 5GB. However, that number automatically started climbing up, and it went up to 40GB, which is what I think was available before.

After that, the PC started freezing. There was a huge delay in mouse movements and app switching, and apps were taking too much time to process a task. So, I went to Activity Monitor and noticed that corespotlightd and kernal_task were taking too much CPU power (both were at around 100%). At that point, I had six apps open actively: Chrome, Mail, Messages, Slack, WhatsApp, and Pages. Plus, there were four apps running in the background: 1Password, Paste, Plex Media Server, and Popclip.

First, I closed all the apps, but that didn't fix the problem. Second, I restarted the PC, but that didn't work either. Third, I deleted the only Pages document I had, which was 'Untitled' (saved in iCloud > Pages), but that also didn't work. Fourth, I have the base variant of the MacBook Pro with M1 SoC as well. I fired it up and found that Pages was one of the apps open in it, and it was displaying the Untitled document that I had deleted from my Mac Mini M4, and the app gave me an option to keep the document or delete it. I chose to delete it, but this didn't solve my problem either.

So, I searched about the issue and stumbled upon this thread. Before doing what people suggested in this discussion, here's what I did, and it solved the problem:

1. I opened Settings > Spotlight and went ahead with Reset Quick Keys and Delete Search History (it didn't fix the problem).
2. SOLUTION - From the top of the Spotlight settings page, I started turning off toggles one by one, including Show Related Content, all the toggles in the Results from Apps and Results from System sections, and Clipboard Search. When I did that, in Activity Monitor, corespotlightd disappeared from the top. Plus, kernal_task also stopped taking high CPU resources. With that, my PC started responding/performing normally (as fast as before).
3. Now, in Settings > Spotlight, I started turning the toggles on from the bottom of the page (from Clipboard Search to Show Related Content). Whenever I turned a toggle on, corespotlightd CPU usage went to around 16% and then came back down.
4. So, I turned all the toggles on, and fortunately, the PC was responding properly, and corespotlightd and kernal_task didn't suffer from high CPU usage. I then opened all the apps, including Pages, and my PC is responding normally (fast). It has been two hours since then, and my Mini M4 is working perfectly.

For people seeing high CPU usage for corespotlightd and kernal_task, they should try doing this. It should fix the problem. I don't know if anyone mentioned this solution before or not. I hope this helps you.

I had this trouble with Sequoia and posted what I learned by talking to Apple support some time ago. It happened again with the Tahoe update, so I repeated what worked before. In Finder, I went to ~/Library/Metadata/CoreSpotlight/ and deleted large folders. That solved the problem. I keep reviewing those folders and deleting them when they grow over a few GB. One time while in that location, I actually saw the a few folders rapidly increasing in size as I watched. This works. I plan to repeat the process preemptively with all new OS upgrades.

Two quick updates from me:

1. To everyone who has joined this thread late: the workaround (there is no solution) to this problem is NOT to make spotlight reindex, to turn off indexing, to turn off (or on) AI stuff, or to try to force the corespotlightd not to run. None of those things will work. The workaround is to delete the corespotlight folder in ~/Library/Metadata. When that folder is on the small side, the corespotlightd process does not cause problems.
2. I can now report back on my own experiment: I've got a script that runs every 2 or so days and automatically deletes the corespotlight folder. I've now been running for more than a week and (knock on wood) everything is fine. I never notice any issues deleting the folder, and by deleting it every couple of days it usually stays under 2 gigs in size (though I've seen it as high as 5 gigs). In my experience, the problems don't start until the folder gets north of 25 Gbs.

Mitch Stone wrote:

Just to be clear, everything we suggest here can be nothing more than a Band-Aid. Only Apple can provide the fix. We are told Apple engineering is monitoring this discussion, so any real-world experiences we can document, and anything that works even as a temporary solution, not only helps us manage the problem in the short term, but perhaps will also point Apple towards the permanent solution we all want.

All this said, based on the now 12(!) pages of discussion since I started this thread, I have become convinced that the problem is Spotlight trying to index documents with a large number of edits. This is exactly how it manifested for me, with an 80k word Pages document being edited by two people with Track Changes turned on. Between us, this resulted in probably more than a thousand edits. Towards the end of the editing, I was seeing beach balling every time I opened this document for more than a few minutes at a time, and had one kernel panic.

Once this editing process was completed, I Finder copied the document. I can now open and make additional edits to the copy without incident. If I watch Activity Monitor (I leave it open in Stage Manager with corespotlightd selected), I will see some spikes in the process, but they are not nearly as high or as prolonged as before, and I also don't see any beach balls. To me, this proves the theory pretty conclusively.

Just to add to Mitch's experiences: I am an inveterate journal-keeper, writing in Pages on a daily basis. It needn't be emphasized that a daily journal grows over time, and by the last couple of months of the year, my Pages journal file is typically over a thousand pages, 750k words or more, which with dozens of embedded graphics will result in a file size between 200–300 MB. Moreover, after nearly a year, we're talking literally tens of thousands of edits. When I was first researching this issue at the beginning of this year, I discovered that my Spotlight metadata had increased on two Intel systems to over 500 GB each. On both machines, Time Machine had essentially ground to a halt, Spotlight search results were useless, both systems suffered multiple kernel panics, and corespotlightd would sometimes pin all CPU cores on both systems, using as much as 1400% of CPU time spread across all sixteen cores (eight of which are virtual hyperthreading cores).

For me, deleting Corespotlight metadata resolved all of these issues. Not permanently; I have to weed out the metadata folders every week to ten days. But so long as I keep that metadata below ~50 GB (on relatively high-performance systems with lots of storage space), my computer life remains pretty peaceful. So long as I remember to quit Pages when I'm not actually using it.

But that said, I was editing my journal file last night, and with that one file open in Pages, which is about 18.5 MB, I watched Spotlight metadata grow by literally a megabyte per second or more, for as long as the file was open. In a single day that would add thousands if not tens of thousands of MB of metadata. But as soon as I quit Pages, metadata growth stopped in its tracks, and was the same value this morning before I left for work, twelve hours later.

YMMV, obviously, but for me these kinds of results could not be more dispositive of the problem here: Spotlight coupled with Pages files with many edits.