macOS 26.1 Tahoe on ARM: FinderSync extension does not work

When running the currently latest version of macOS (26.1) on a machine with an ARM CPU (I could not reproduce the issue with Intel-based machines), Finder Sync extensions do not work anymore in general.

Have you filed a bug on this and, if so, what is the number?

Any ideas what I could be missing here?

Have you reproduced this on dedicated test machines (where nothing else is installed) or is this only happening on end-user machines?

I have a post here that talks about this in more detail. What typically causes this is "nesting" FinderSync extensions. Also, are you specifically placing contents in "/Users/Shared", or was that just a convenient location you selected for testing purposes? That particular directory is not one I'd recommend any developer really "use", as the combination of open permission (so "everyone" can modify it) and a "known" location (so all sorts of "random" apps could be interacting with it) means that it isn't really a location you can "trust".

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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

Yes, I have already filed a bug, it's number is FB20947446.

OK. The engineering team hasn't had a chance to look at it yet, but I can immediately tell you that they're going to need a sysdiagnose from the machine where the failure is happening.

"/Users/Shared" is the default path which is used in the Xcode template when creating a Finder Sync Extension.

Oh. I can see why they used that in the template (it's basically the only "user path" they can guarantee exists), but that's still not... ideal.

However...

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.

...it should work fine for basic testing, particularly on a dedicated test machine.

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.

OK, that's fine. However, not that the Finder Sync Extension point has basically been replaced by replicated file provider for apps doing "sync".

What exactly do you mean with "nesting" FinderSync extensions?

This happens when one FinderSync extensions target directory is inside the target directory of another FinderSync extension. The typical case here is a app that's trying to act as a "general" extension for the Finder, so it targets a "broad" directory like the users home director or even "/". A extension which uses a designated directory inside the users home folder is now "nested" inside the other extension.

The problem with this is that it doesn't really work. The Finder makes no attempt to account for this, so one of the extension is not going to work inside that nested directory.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

OK. The engineering team hasn't had a chance to look at it yet, but I can immediately tell you that they're going to need a sysdiagnose from the machine where the failure is happening.

Please take a look at the sysdiagnose you uploaded to the bug. If you uncompress the log, you'll find the following:

• Inside "crashes_and_spins", ~120 crash logs from your extension. Sampling those logs, all of them showed you crashing with this stack (more details on that shortly):

 Thread 3 Crashed:: Dispatch queue: 
0  libsystem_kernel.dylib     	       0x7ff809673826 __pthread_kill + 10
1  libsystem_pthread.dylib    	       0x7ff8096afb5a pthread_kill + 259 
2  libsystem_c.dylib          	       0x7ff8095c0376 abort + 126 
3  com.apple.finder.FinderSync	       0x7ffb16fc19be -[FIFinderSyncExtension begin] + 718 
4  com.apple.Foundation       	       0x7ff80a9ca9a5 __NSXPCCONNECTION_IS_CALLING_OUT_TO_EXPORTED_OBJECT_S0__ + 10 
5  com.apple.Foundation       	       0x7ff80b575b47 -[NSXPCConnection _decodeAndInvokeMessageWithEvent:reply:flags:] + 1656 
6  com.apple.Foundation       	       0x7ff80b5775fa message_handler_message + 80 
...
30  libdispatch.dylib          	       0x7ff809505705 _dispatch_workloop_worker_thread + 871 
31  libsystem_pthread.dylib    	       0x7ff8096ac869 _pthread_wqthread + 298 
32  libsystem_pthread.dylib    	       0x7ff8096ab843 start_wqthread + 15

• If you open the system_logs.logarchive and pick any one of your extension processes, you'll find that the last lines logged (before you crash) are all:

2025-11-07 13:32:56.454892+0100 <bundle id>: (ExtensionFoundation) [com.apple.extensionkit:default] NSExtensionPrincipalClass `<class name>` does not conform to NSExtensionRequestHandling protocol!
2025-11-07 13:32:56.455108+0100 <bundle id>: (ExtensionFoundation) [com.apple.extensionkit:NSExtension] in _willPerformHostCallback: block ( UUID: 705805DD-F751-4746-BD76-FCE82BD1B1A4 error: (null) )

• Following the lines above, you'll also find a similar entry from "ReportCrash" that is actually the message from the "abort()" call in your crash above.

2025-11-07 13:32:56.664650+0100 ReportCrash: ASI found [FinderSync] (sensitive) 'A FinderSync extension's NSExtensionPrincipalClass ((null)) must be a subclass of FIFinderSync.'

I obviously don't have any knowledge about your extensions implementation, but every indication here is that this is a bug in your code.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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 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.

Are you able to enable any of them? I don't think any of them should work. If you look in the file "sysdiagnose.../SystemProfiler/SPConfigurationProfileDataType.spx", you'll find this configuration profile:

com.apple.NSExtension:
....
  Identifier:	7AEEFC77-1698-4E89-A62E-4CDE92176EFB
  UUID:	7AEEFC77-1698-4E89-A62E-4CDE92176EFB
  Version:	1
  Payload Data:	{
    AllowedExtensions =     (
		...
    );
    DeniedExtensionPoints =     (
        AllPublicExtensionPoints
    );
}

...which I'd expect to prevent all FinderSync extensions from loading. I'll also note that there's an EndpointSecurity extension active, which can also have unexpected results.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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.

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.

This is now the 3rd sysdiagnose you've uploaded. Before uploading another, please take the time to investigate the data instead of assuming there is a system-level issue, as there is every indication that this is in fact a problem with how you've configured these machines.

Case in point:

I've uploaded a new report which now should correctly contain everything with the Xcode example. Even the reinstallation of the OS did not help.

This is not a system bug, as the system is behaving exactly the way MDM has configured it.

More specifically:

• In the bug, you specified this bundle "<redacted id>.TestFinderSyncExtension" as the one to look for. If you search the system_logs.logarchive for that file, you'll find that the first message returned is the message pdk logs when it's intentionally denying an extension due to MDM:

2025-11-17 10:57:52.314553+0100 pdk: (ConfigurationProfiles) [com.apple.ManagedClient:ManagedClient] Denying plugIn '<redacted id>.TestFinderSyncExtension' due to MCX management

• As I described above if you open the file "SPConfigurationProfileDataType.spx" (or open up "System Information.app" on the test machine) and look at the configuration "MDATP MDAV System Extensions", you'll find this configuration which is blocking your extension:

MDATP MDAV System Extensions:

  Description:	MDATP system extensions
  Organization:	<redact>
  Installation Date:	Thursday, 13. November 2025 at 14:13:03 Central European Standard Time (2025-11-13 13:13:03 +0000)
  Identifier:	F824CADE-B012-46EA-9B5E-304A5E3C000C
  UUID:	F824CADE-B012-46EA-9B5E-304A5E3C000C
  Version:	1
  Verification State:	Verified
  Source:	MDM
  Removal Disallowed:	Yes

com.apple.NSExtension:

  Description:	
  Organization:	<redact>
  Name:	EXTENSIONS
  Identifier:	7AEEFC77-1698-4E89-A62E-4CDE92176EFB
  UUID:	7AEEFC77-1698-4E89-A62E-4CDE92176EFB
  Version:	1
  Payload Data:	{
    AllowedExtensions =     (
        "com.microsoft.wdav.epsext",
        "com.microsoft.wdav.netext"
    );
    DeniedExtensionPoints =     (
        AllPublicExtensionPoints
    );
}
...

I've uploaded a new report which now should correctly contain everything with the Xcode example. Even the reinstallation of the OS did not help.

I'm not an expert on MDM, but I think that a source entry of "CloudConfiguration;SetupAssistant":

Device Configuration Profiles:

MDM Profile:

  Description:	MDM Profile for mobile device management
  Organization:	<redact>
  Installation Date:	Thursday, 13. November 2025 at 14:10:19 Central European Standard Time (2025-11-13 13:10:19 +0000)
...
  Source:	CloudConfiguration;SetupAssistant

...might indicate that the profile was installed by Automatic Device Enrollment (ADE) during system installation. That would create this configuration without any specific action or configuration on your part.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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.

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.

Yes, I can certainly understand and wish this was handled better. However, I can provide a bit more context about why this was specifically happening.

Across our technology stack, there are often many points where any given "block" could be implemented, with the general trade-off being that lower-level blocks are harder to bypass but also make it more difficult to provide "feedback" as to what's actually happening. There are exceptions, but in general, our MDM "blocks" tend to be implemented at lower levels of the system at points that minimize the "disruption" to the rest of the system. This both makes them harder to bypass and reduces the risk that they'll cause other problems. That leads to here:

the extension appeared enabled although it was disabled in the background

That's because, as far as the high-level system was concerned, it WAS enabled. The particular block that's happening here is a low-level block within ExtensionKit that applies to "all" extension points. How it actually works is that all of the "normal" ExtensionKit machinery (including enable/disable) continues to function exactly as it usually would, with the only "block" being at the point where we ACTUALLY try and execute the extension point. The net result is that half of the system (the part that manages enable/disable) sees everything as working completely normally, while the other "half" (the part that actually runs the extension) is being told that nothing is installed at all. This is secure and low risk, but yes, it also means that the interface is basically "broken".

That leads to the larger point. MDM configuration is a "expert" level settings system, where the profile "owner" is expected to understand and document the consequences to their users. The reality is that MDM systems are sufficiently complex that it would be difficult for the system to accurately communicate what a configuration "does" and sufficiently powerful that there's no guarantee that the system could actually communicate what it "found". It's possible some of these details could improve over time, but I think it will basically "always" be possible for an MDM profile to break the system in ways that won't be obvious to the user. I don't see how we'd provide a solution as powerful as MDM that avoids that.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware