Ah, exactly. Thank you!

Sorry, responded in the comment section. Duplicate as a reply: Ok, considering only the real product: The UI element app is an app, right? Not something else, like an app extension. Exactly, that is an app not an app extension or anything else Are either of these sandboxed? They aren't sandboxed Where did you app the Apple event capability? On the UI element app? Yes, on the UI element app via Xcode "Signing & Capabilities" In that TCC error, which bundle ID and path are shown? The container app? Or the UI element app? UI element app

Tested with your suggestion the issue persists. The error message from tccd persists, the UI element app app gets closed on calling SBApplication(bundleIdentifier:). No crash reports in Console.

Hi, eskimo! Finally, I was able to check that. This termination mystery was solved: an exit() statement caused app termination. The statement was in the program itself and it had nothing in common with tccd. However, the issue with tccd that caused the creation of this thread persists. It continues to report the absence of entitlements for Apple Events despite the fact, that the bundle has it. If we return to our naming convention: "UI element app" is a user agent that has the corresponding plist and gets launched via launchctl command from "container app". UI element app bundle is a part of the container app bundle. Considering these conditions is it possible that the issue may be with the container app not having the required entitlements?

Probably you are right, I am going to check with your suggestions, thank you! So far I have modified the UI element app so I can run it as a standalone GUI-less app (via Xcode without launchctl invocation or by double-clicking on the bundle). By GUI-less I mean with "Application is agent" key set to YES in Info.plist and without "Main storyboard" key. In this configuration, the app can acquire Automation permissions and interact with Finder via Scripting Bridge.

@DTS Engineer checked with your suggestion to add AssociatedBundleIdentifiers. Whilst tccd now doesn't report this particular error GUI app still doesn't request automation permission (which happens when I run it as a standalone process) on SBApplication call.

@DTS Engineer So, here is what I have investigated. If I put the application bundle inside another bundle I should set entitlements and Info.plist accordingly for both container and nested app. In that case despite the way you are launching a nested application (either via launchctl utility or via Service Management framework). With this setup, I could finally see the message about the process asking for Automation permission. However, the application name in the message wasn't the container's not the nested app's.

Sorry, writing a response during the night in a foreign language was a bad idea... I mean, I have a "container" bundle and a "nested" bundle which I put in "container".app/Contents/MacOS. The container application launches the nested one as an agent. I tested launching via launchctl and Service Management framework. It turns out that I have to put "Apple Events" entitlements for both the container and the nested app and update their Info.plists accordingly (put there Privacy - AppleEvents Sending Usage Description), even though only the nested app deals with Scripting Bridge. When a nested app reaches the execution point where it invokes Scripting Bridge API a corresponding popup from the system appears to get the user verdict (allow/deny access). However, the message in this popup states that Automation permission is requested by a container app that doesn't deal with Apple Events and acts as a simple launcher for the nested one. It turns out that I didn't need AssociatedBundleIdentifiers in the nested app's Info.plist (so far, I don't know whether it could a problem for notarization).