Additional information: Sometimes the error is like 2024-01-04 07:48:52.206 xcodebuild[3792:17291] Error: execSQLStatement:onConnection:toCompletionWithRetry:writeLockHelp - SQL=CREATE INDEX time_stamp_index ON cfurl_cache_response(time_stamp);, error-code=1, error-message=index time_stamp_index already exists 2024-01-04 07:48:52.206 xcodebuild[3792:17291] ERROR: NSURLStorageURLCacheDB _setDBSchema: DB=/Users/vagrant/Library/Caches/com.apple.dt.xcodebuild/Cache.db table index on time_stamp - index time_stamp_index already exists. ErrCode: 1. Are there some more error conditions possible in that scenario?

Thank you for your quick response! Yes, I have already filed a bug, it's number is FB20947446. We can reproduce the issue on "normal" end user machines where nothing special is installed or configured. One particular machine where the problem occurs is a MacBook Pro, 13-inch, M1, 2020 with 16 GB of memory and macOS Tahoe 26.1. One machine there the problem does not occur is a MacBook Pro, 16-inch, 2019, 2.3 GHz 8-Core Intel Core i9 with 32 GB of memory and Tahoe 26.1. "/Users/Shared" is the default path which is used in the Xcode template when creating a Finder Sync Extension. I thought that for reproduction purposes it would be good to just use that as it is to make sure that there is no mistake on my side. And I assume that the template should work by default. The location that is used in our product where the problem also occurs is located in the current user directory, where I suppose that it is common to place files that should be synchronized, for which purpose the Finder Sync Extension is designed. What exactly do you mean with "nesting" FinderSync extensions? Thank you and regards, Dominik

I have added a sysdiagnose from the ARM machine where the problem occurs to the feedback/bug report. What I tried is to disable every Finder Sync extension that I could find in the system settings except the example extension, but that did not help sorting out the problem.

I've mistakenly created that diagnosis report just after a reinstallation of the OS, but the Xcode example (or any other Finder Sync Extension) was not running yet on that machine. I've uploaded a new report which now should correctly contain everything with the Xcode example. Event the reinstallation of the OS did not help.

Thank you for your time and looking at this, the issue was indeed caused by security software disabling extensions. What we still might consider a "bug" would be that there was no indication of that in the user interface - the extension appeared enabled although it was disabled in the background.

Hello! Thank you for your reply! The high-level goal here is to implement certificate verification for the use of libcurl built with openSSL (CURLOPT_SSL_CTX_FUNCTION/SSL_CTX_set_cert_verify_callback) as we currently use that HTTP stack for all platforms of our software (macOS, Windows, Ubuntu) and it would be quite an effort to change that to use native HTTP APIs from the operating system, and for security reasons revocation check should also be done here like the browsers do. Since libcurl version 8.15 the curl-built-in support for "Secure Transport" was removed, as it is deprecated and does not support TLS 1.3, therefore we want to use openSSL as the SSL backend instead, which lacks keychain access. See: https://github.com/curl/curl/pull/16677 https://curl.se/mail/lib-2025-08/0048.html I've just made a quick and dirty sample for reproduction purposes ;-)