[BUG] Settings window hangs indefinitely due to synchronous Spotlight query on corrupted mds_stores

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Opening Claude Desktop's Settings window beachballs the entire app, requiring force-quit. The hang is deterministic on any macOS system where Spotlight has entered emergency state on any indexed volume. Process sampling shows the wedge is inside Claude Desktop's own code — InstalledAppsCache.performSpotlightQuery in computer_use.node — issuing a synchronous NSMetadataQuery attribute fetch via an XPC send that has no timeout. When mds_stores is in emergency state, the send never returns, and the UI thread is pinned indefinitely.

Severity from my perspective as a user: High. I cannot access Settings at all. This means I cannot install, remove, or configure MCP connectors, cannot change any Desktop-specific preferences, and cannot authorize new extensions. Every other part of Claude Desktop works normally; Settings is the single affected surface, and it's the one surface I need to use whenever my environment changes.

Environment

• macOS Sequoia (current release), Intel Mac
• Claude Desktop: latest release (auto-updated on launch)
• Spotlight state: mds_stores on iCloud Drive volume has been in emergency state for weeks. This is confirmed by system log entries such as:
• mds_stores: (SpotlightIndex) [com.apple.spotlightindex:IVFVectorIndex] IVFVectorIndex::unlink <private> failed 0 <private>
• mds_stores: (SpotlightIndex) [com.apple.spotlightindex:SDB] db2_deserialize_cache_block_invoke:15416: invalid sdb page in cache 5
• mds_stores: (SpotlightIndex) [com.apple.spotlightindex:CI] _CISetEmergency:82: Setting index emergency state

The underlying Apple problem

I want to make clear that the Spotlight corruption itself is an Apple issue that users cannot resolve through normal means on Sequoia. I have confirmed this across multiple attempts:

1. Full mdutil -E rebuild of the Data volume (the standard Apple-recommended repair) completes but mds_stores returns to emergency state almost immediately on the iCloud volume. The underlying IVFVectorIndex corruption re-emerges during reindexing.
2. mdutil -i off against the iCloud path fails with Error: invalid operation. Error: unknown indexing state. because mdutil cannot manage File Provider–mounted volumes directly.
3. .metadata_never_index sentinel files are no longer honored in Sequoia (documented change from earlier macOS versions).
4. System Settings → Spotlight → Search Privacy, adding iCloud via drag-to-exclude (using a symlink since ~/Library/Mobile Documents is hidden from Finder) appears to register in the UI, but process sampling confirms it has zero effect on NSMetadataQuery behavior — the API layer InstalledAppsCache.performSpotlightQuery uses does not honor the Privacy exclusion.
5. killall mds_stores restarts the process, which inherits the same corrupted on-disk state and returns to emergency within seconds.
6. Granting Terminal Full Disk Access did not change mdutil's ability to manage the iCloud volume.

The only user-side remedy I have not attempted is a full iCloud Drive sign-out with local-data wipe and sign-back-in — a roughly two-hour disruptive operation that is not a reasonable prerequisite for using a desktop app's Settings window.

The practical conclusion: this is not a bug users can work around. The Apple-side fix is out of reach. The Anthropic-side fix is straightforward.

Root cause from process sampling

A 10-second sample taken while the Settings window was beachballed shows the process thread pinned on the following call stack for the full sample duration (counts in the thousands of samples):

closure #1 in closure #1 in static InstalledAppsCache.performSpotlightQuery()
  (in computer_use.node)
  → -[NSMetadataItem valueForAttribute:]  (in Foundation)
    → MDItemCopyAttribute  (in Metadata)
      → fetchAttributesForItems  (in Metadata)
        → sendServerMessageWithTimeout  (in Metadata)
          → xpc_connection_send_message_with_reply_sync  (in libxpc.dylib)
            → dispatch_mach_send_with_result_and_wait_for_reply  (in libdispatch.dylib)

Multiple closures within performSpotlightQuery hit the same wedge (offsets +582, +770, +970, +1038, +1420 all show the same terminal XPC block). The function is clearly iterating over NSMetadataItem results and fetching attributes synchronously per item.

The _sync suffix on xpc_connection_send_message_with_reply_sync is the specific problem. This variant has no timeout and no cancellation. When mds_stores is in emergency state, the reply never arrives, and the calling thread blocks forever.

The full filtered sample output is attached separately. The pattern is reproducible on every Settings open.

Impact

Because Settings is the only way to modify Claude Desktop's local configuration, I currently cannot:

• Add, remove, or reconfigure any MCP connector or extension
• Change auto-update, notification, or window behavior preferences
• Manage account-level settings accessible only from the Desktop app
• Review or modify permissions for existing connectors

Everything else in Claude Desktop works normally — conversations, tool use, the Filesystem MCP, web search, file reads and writes. But the app's local configuration surface is completely inaccessible, which is a significant ongoing impairment. Any future change I want to make to local configuration requires either fixing the underlying Apple bug (which I cannot) or this bug being fixed.

Related issues on GitHub suggest this affected-user population is small but real:

• #2230 — blank screen when invoking MCP tools (different symptom, related infrastructure)
• #28353 — blank screen crash (different root cause, but similar pattern of synchronous wedge)

Recommended fix

Any of the following would resolve the hang. Listed in order of increasing intrusiveness.

Option A — Add a timeout to the XPC send. MDItemCopyAttribute and related APIs fundamentally have to talk to mds_stores, so bypassing them isn't an option, but a timeout would convert an infinite hang into a recoverable error. The Metadata framework already has a sendServerMessageWithTimeout wrapper visible in the sample trace; presumably the timeout parameter can be set.

Option B — Use async NSMetadataQuery completion blocks instead of synchronous per-item attribute fetches. This is the Apple-recommended pattern for NSMetadataQuery. Results arrive via NSMetadataQueryDidFinishGatheringNotification and handler blocks; the main thread never blocks on mds_stores.

Option C — Pre-check Spotlight health before issuing the query. mdutil -sa returns within milliseconds and reports per-volume indexing state. If any volume reports unknown indexing state or the Data volume reports Indexing disabled, the app can skip performSpotlightQuery entirely and present an empty or graceful-degradation state for whatever Settings feature depends on the installed-apps list. This is the quickest fix if the installed-apps cache is only used for UI decoration.

Option D — Move performSpotlightQuery off the UI thread. Whatever the backend, the UI thread should never wait on a synchronous XPC send. This is orthogonal to A, B, and C and should be fixed regardless.

I suspect Option A or D alone would eliminate the user-visible hang while leaving the underlying Settings functionality intact. Option B is the structurally right fix.

Reproduction

Any one of the following will reproduce the hang:

1. On any Mac with existing Spotlight corruption on any indexed volume (check sudo log show --predicate 'process == "mds_stores"' --last 1h | grep -i emergency), open Claude Desktop and click Settings.
2. On a healthy Mac, artificially induce the wedge with: sudo launchctl stop com.apple.metadata.mds_stores just before opening Settings. The query will hang while mds_stores is stopped.
3. Set up a test harness that delays or drops XPC replies to Metadata framework requests, then call NSMetadataQuery via the same pattern InstalledAppsCache.performSpotlightQuery uses. Confirm synchronous attribute fetch hangs indefinitely.

Attachments

• Full process sample output (10-second sample, filtered to show Metadata / Spotlight / Spotlight-related frames): [attach the claude-settings-hang-filtered.txt file]

Requested acknowledgment

I would appreciate:

1. Confirmation that the report has been received and triaged.
2. An indication of whether this is on a fix path, and if so, a rough timeframe.
3. A workaround, if one exists inside Claude Desktop, that lets me access Settings without triggering performSpotlightQuery (e.g., a command-line flag, environment variable, or alternate settings entry point).

Thank you.

What Should Happen?

I should be able to open settings without the app hanging.

Error Messages/Logs

Steps to Reproduce

Reproduction

Any one of the following will reproduce the hang:

1. On any Mac with existing Spotlight corruption on any indexed volume (check sudo log show --predicate 'process == "mds_stores"' --last 1h | grep -i emergency), open Claude Desktop and click Settings.
2. On a healthy Mac, artificially induce the wedge with: sudo launchctl stop com.apple.metadata.mds_stores just before opening Settings. The query will hang while mds_stores is stopped.
3. Set up a test harness that delays or drops XPC replies to Metadata framework requests, then call NSMetadataQuery via the same pattern InstalledAppsCache.performSpotlightQuery uses. Confirm synchronous attribute fetch hangs indefinitely.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

4.6

Claude Code Version

Claude 1.3109.0 (35cbf6) 2026-04-16T20:32:01.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_