Same root cause we worked around in TestFS — sharing data and our fix in case it helps We hit this on macOS 26.4.1 in a third-party FSKit V1 block-resource extension shipped via a Sparkle-auto-updated host app (com.sohonet.testfsmount.appex inside TestFS.app). Reproducible cycle: Fresh install: mount works. Auto-update replaces /Applications/TestFS.app. System Settings → Login Items & Extensions → File System Extensions still reads "TestFS — on." mount(8) -F -t testfs /dev/diskN /tmp/foo fails: mount: Loading resource: The operation couldn't be completed. (com.apple.extensionKit.errorDomain error 2.) mount: File system named testfs not found mount(8) exits 69 (EX_UNAVAILABLE). Toggling the System Settings switch off and then back on always fixes it. So does waiting some unspecified amount of time, or invoking mount(8) against a different /dev/diskN after a fresh hdiutil attach cycle (apparently triggers re-resolution). Reading lsd and extensionkitservice logs against the same time window suggests lsd re-registers the appex with a new internal UUID after the bundle replacement, but extensionkitservice keeps a handle to the previous UUID, so the lookup-by-fstype fails until something forces re-adjudication. Workaround that's working for us On every app launch, we compare the running CFBundleVersion against a stored value in UserDefaults. If they differ (i.e. the app was just replaced — first launch in the new bundle), we shell out to: /System/.../LaunchServices.framework/.../lsregister -f /Applications/TestFS.app /usr/bin/pluginkit -a /Applications/TestFS.app/Contents/Extensions/TestFSExtension.appex …then save the new version. Subsequent launches with the same version skip the re-register. Net effect: by the time the user clicks Mount, extensionkitd has already re-resolved the new bundle. This is the same workaround macFUSE 5.2.0 release notes describe shipping for the same class of issue: https://macfuse.github.io/2026/04/09/macfuse-5.2.0.html Things I'd love to know from Apple Is lsregister -f + pluginkit -a from inside the just-launched .app the right approach, or are we masking a deeper bug we should be filing instead? Is there an FSKit / ExtensionKit API we should be calling on launch ("force re-adjudication") rather than shelling to CLI tools? Does Apple have an internal radar already tracking the lsd / extensionkitservice UUID-mismatch story? Happy to add a fresh Feedback Assistant report if helpful — would just rather link to the existing one if one exists. Source repo: https://github.com/sohonetlabs/testfs (workaround in AppEnvironment.reregisterExtensionIfNeeded() if anyone wants to copy the pattern).