Thanks for the clarification, Quinn. That explains why the hang occurs and why the first AppleScript call needs to run on the main thread. In my case, the problem is that this behavior appeared without documentation. My app legitimately automates Mail and has done so for years. Running AppleScripts from background threads is a normal pattern for this kind of software. Having the first call suddenly require main-thread initialization is a significant behavioral change. There are some practical issues for developers: • The change is not documented. • The hangs are non-deterministic. • There is no API to trigger or control the initialization. • There is no error or diagnostic that would help identify the cause. I understand that AppleScript can be an attack surface and that XProtect integration may be intentional. However, the current approach affects legitimate uses without giving developers a supported way forward. If the platform requirement is that the first AppleScript runs on the main thread, Apple should state this clearly. Undocumented technical hoops do not stop attackers. They only make life harder for developers who are trying to use the system in a supported way. I would appreciate it if you could pass along that this change has real-world impact on existing shipping software, and that documentation or a simple API would avoid a lot of confusion. Thanks again for your time.

After updating to the latest XProtect version I was able to see the hang, too. I've added a sysdiagnose to the ticket.

Some more information: My AppleScripts usually are very simple because the app does the heavy lifting. Think getting the accounts for Mail or the account type. I have 2 places in the app where I use AppleScript. In the Setup the users determines which email she wants to archive from Mail. And then the user can archive the emails to a database. The Setup uses the AppleScripts in a thread. Archiving is threaded, too. But the AppleScripts are run on the main thread and before threading starts. The scripts run fine on the main thread. These are the same scripts which are used in the Setup!!! I've moved the first AppleScript to osascript and now the second script hangs which is still using NSAppleScript. The plan for today is to move more AppleScripts to osascript.

I've got the same error today so the bug is not fixed!

Of course, you are correct. I'm using Xojo and the code is a bit different. I have a class to remove files. It gets the authorisation and the uses Filemanager with authorisation to delete some files: Private Property theFileManager As NSFileManagerMBS Public Sub Constructor(hasAppName as String, hasAuthorization as NSWorkspaceAuthorizationMBS, doRegistration as Boolean) AppName = hasAppName myAuthorisation = hasAuthorization theFileManager = NSFileManagerMBS.fileManagerWithAuthorization(myAuthorisation) DeleteApp if doRegistration then removeRegistration End Sub And Delete App: AppFolder = SpecialFolder.Applications if AppFolder <> nil and AppFolder.Exists then AppFolder = AppFolder.Child(AppCommon.getInstallationAppName) if AppFolder = Nil or not AppFolder.Exists or not AppFolder.Directory then Return dim theError as NSErrorMBS dim theResult as Boolean = theFileManager.removeItem(AppFolder, theError)

I get the same error using the Xojo IDE (url not permitted). The debugged app has an ad-hoc code certificate. Shouldn't this be enough for Instruments? macOS 11.2 and Instruments 12.5. Problem solved: was missing the correct entitlement.