mdworker eating your CPU on macOS? Here's what to do in 2026

If your fans suddenly sound like a jet engine and Activity Monitor shows a process named mdworker_shared or mds_stores near the top, you have already met Spotlight's indexer. On a healthy machine the indexer should be invisible — it runs in low-priority bursts and finishes in minutes. On macOS Sequoia and Tahoe 26, "healthy" has been a moving target. This guide collects every fix that has actually worked across two macOS generations, ordered from least to most invasive.

The short version: do not panic, do not nuke Spotlight, and do not give up the keyboard. A local-only launcher like CmdSpace keeps ⌘Space useful while you wait the indexer out.

What `mdworker` and `mds_stores` actually do

mds is the Spotlight indexing daemon, and mds_stores is its long-lived child that writes index data to disk. mdworker_shared is the per-importer process that opens specific file types, extracts metadata, and hands it to mds. When you see one of them at 200% CPU for hours, something has gone wrong upstream — usually a corrupted index, a path that imports very slowly, or a runaway re-index after a macOS update.

Michael Tsai's July 2025 round-up is the best read for context. He documents the bug across Sequoia point releases, with reports continuing into Tahoe betas.

Step 1 — Confirm it really is Spotlight

Before changing anything, sample the process. Open Terminal and run:

sudo fs_usage -w -f filesys mds_stores | head -40

You should see the indexer touching files in real time. If fs_usage shows nothing while Activity Monitor still reports high CPU, the culprit is probably a different process with a similar name (Spotlight Suggestions, parsecd, or a third-party indexer like Dropbox). Treat each by its own fix; Spotlight is not always to blame.

Step 2 — Wait one hour

This is the boring answer that works more often than people expect. A first-time index after a macOS upgrade can take anywhere from 20 minutes on a small SSD to several hours on a 4 TB external drive. Plug into power, leave the machine awake, and check back later.

If progress has visibly stalled — same files showing up in fs_usage, same CPU plateau, no shrinkage of pending counts — move on.

Step 3 — Check the indexer's actual state

macOS ships mdutil, a CLI that reports per-volume indexing status:

mdutil -s /
mdutil -s ~
mdutil -s /Volumes/Backup

The output tells you whether indexing is enabled, whether it is currently scanning, and whether the index appears valid. If you see "Indexing and searching disabled" on / but Spotlight is still chewing CPU, the daemon is stuck on a transient store and will not progress until you rebuild.

Step 4 — Exclude the noisy paths

Most "Spotlight is destroying my Mac" stories trace back to two or three folders that should never have been indexed in the first place:

Anywhere a node_modules, .venv, target, build, or vendor directory lives
Time Machine destinations and backup snapshots
Large media libraries on slow external disks
Synced cloud folders that change constantly (iCloud Drive subfolders, Dropbox)

Open System Settings → Spotlight → Privacy, click +, and add each path. macOS pauses indexing on the path immediately and removes its existing entries within a minute. To do it from the command line for a single volume:

sudo mdutil -i off /Volumes/Backup

There is a long-running community thread on MacRumors about mdworker_shared flooding the system log; the consensus fix is exactly this — exclude the path, do not turn the indexer off globally.

Step 5 — Rebuild the index

If exclusions did not calm things down, the index file itself is probably corrupted. Rebuilds are cheap on Apple Silicon and almost always safe:

sudo mdutil -E /

-E erases the index and triggers a full re-scan. Expect the same CPU spike for a while, then a long tail of quiet maintenance. OSXDaily's Sequoia walkthrough covers the same command and is still accurate on Tahoe 26.

If you have multiple internal volumes (Data, Recovery, VM), rebuild only the Data volume:

sudo mdutil -E /System/Volumes/Data

Step 6 — Reset Spotlight preferences

A subset of users on Tahoe 26 report that the indexer respects exclusions only after a preferences reset:

killall mds
sudo rm -rf /.Spotlight-V100
sudo mdutil -E /

The first command stops the daemon. The second deletes the on-disk index folder at the volume root (it will be recreated). The third triggers a fresh build. Reboot after this if mds_stores still does not behave.

Step 7 — Decide what you actually need Spotlight for

Most of the people I know who hit this bug end up in the same configuration: Spotlight stays on, but with a narrow scope — Applications, System Settings, maybe Documents — and the ⌘Space hotkey moves to a launcher that does not touch the metadata indexer at all.

That is where CmdSpace fits. It runs its own local-only index (Rust-backed, sub-25ms on a 250k-file tree) and never asks mds for anything. If Spotlight rebuilds for an hour, CmdSpace keeps working. If Apple ships a fix in the next point release, Spotlight comes back and you have lost nothing.

If you want to try the migration, see our migration guide. It walks through detaching ⌘Space, trimming Spotlight's scope, and verifying the change end to end.

When to escalate to Apple

If you have run every step above and mds_stores still climbs above 200% CPU for sustained periods, this is a real bug, not a configuration problem. File feedback through Feedback Assistant with a spindump of the process attached, and link Michael Tsai's post as prior art. The more reports Apple sees with consistent symptoms, the more likely a fix lands in a point release.

What mdworker and mds_stores actually do