The new Apple Event sandbox in macOS 10.14 Mojave lacks essential APIs

Number:rdar://41570203 Date Originated:June 28, 2018
Status:Open Resolved:
Product:macOS + SDK / Foundation Product Version:18A314h
Classification:serious bug Reproducible:always
The Apple Event Sandbox implementation as of macOS 10.14 Mojave beta 2 (18A314h) lacks essential APIs that apps would need to adapt to and provide a good user experience around the change.


I identified these issues with the current implementation:

1) timing: apps don't have sufficient control over when the user is prompted for authorization

2) adapting UI: apps have no guaranteed non-interactive/-blocking way to know if they're authorized to send AEs to another app to adapt their UIs

3) apps can't avoid getting stuck indefinitely if there's no one to answer the auth prompt (problem for remote/MDM/accessibility apps) 

4) authorization requires launching the target app. Makes on-boarding for tools targeting many apps a UX nightmare.

5) even if trusting an app targeting a large (or even open-ended) list of other apps, users can't whitelist it to avoid constantly running into auth prompts.

6) authorization can't be re-requested. F.ex. in response to a click on an "Authorize" button in an alert stating that the app lacks a permission.

7) lack of context: users lack usage descriptions to inform their decision.


What's missing:

1) an API to get the current authorization status without launching the target app, similiar to +[AVCaptureDevice authorizationStatusForMediaType:] or AXIsProcessTrustedWithOptions(). API idea:

+ (NSAppleEventAuthStatus)authorizationStatusForTarget:(nullable NSAppleEventDescriptor *)eventDesc;

"eventDesc" identifies the target app. Passing nil returns the app's whitelist status (see pt. 3).

The return value represents the current status:
- not determined (user not prompted yet)
- denied
- authorized

2) an API to prompt without launching the target app, similar to +[AVCaptureDevice requestAccessForMediaType:completionHandler:] or AXIsProcessTrustedWithOptions().

It should be possible to bring up the prompt even if it has been brought up before. API idea:

+ (void)requestAccessForTarget:(nullable NSAppleEventDescriptor *)eventDesc options:(NSAppleEventAuthOptions)options completionHandler:(void (^)(BOOL granted))handler;

"eventDesc" identifies the target app. Passing nil opens System Prefs showing "Automation".
"options" allow to show the prompt even if it was shown before.
"handler" is called with the result.

3) an option in System Prefs to "whitelist" apps, which can then send AEs to any other app (similar to what the new "Application Data" category achieves for file access). UI ideas:

4) support default and app-specific usage descriptions in prompts.

5) a way for apps to opt out of automatic prompts (as triggered by sending an AE) altogether. Apps that opted out should be returned errAEEventNotPermitted, until the apps brought up the auth prompt (via the API from pt. 2) and won the user's approval.


Due to length constraints, I couldn't include more examples and details on the suggested APIs in this radar. For these, please see my post on this topic:


Number Status Originator Product Title
rdar://41630689 Duplicate/41570203 pierre.bernard macOS + SDK: Automation Mojave Automation security has bad user experience




By sindresorhus at Oct. 8, 2018, 7:04 p.m. (reply...)



Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!