Can't get app added to Privacy/Automation

The user has 2 computers. One one computer my app works fine. On the second one the app is declining Automation approval on it’s own. I let the user reset Automation with a Terminal command. Then I made him a test app with the following code from the MBS plugin examples:

dim target as NSAppleEventDescriptorMBS = NSAppleEventDescriptorMBS.descriptorWithBundleIdentifier("")

// we ask for all apple events
dim e as integer = NSAppleScriptMBS.DeterminePermissionToAutomateTarget(target, "****", "****", true)
if e = 0 or e = -1 then
  MessageBox "everything okay"
  MsgBox str(e)+": "+errorToString(e)
end if

The full app has the usual plist, codesign, notarisation. I made sure that the test app has the same.

Neither the full app or the test app show up in the Automation pane at all for the user.

Instead of getting the usual “blabla wants to control Mail” the result is an error -1743: Not permitted. Any ideas what else I could try to get Automation working?

Has your user tried to restart its computer?
I’ve seen such restarts reset weird things regarding the “new Apple privacy system”.

Thanks, I think I forgot to ask the user to restart. §$%& security.

1 Like

You’re welcome; though it can be very well another issue.

Can we still name it that way? That’s rather a “lock out”…

1 Like

I now had reports from 3 users that they can’t get access to Automation.

They all restarted their computer. No change.

I made another test version with a different bundle id. But I didn’t get anyone to test that - too complicted.

I suggested for 2 of them to contact AppleSupport. I hope that they get back to me. I’m going to do a Zoom session with the third tomorrow.

One user has 2 computers - one with Crapolina and one with Monterey. My app makes problems on Crapolina. Monterey is fine.

The only change I did compared to the last version of my app is that the app is now universal.

Out of ideas…

Send me the test app and some basic reproduction steps.

@Sam_Rowlands : thanks.

One user solved the problem on his own. I just did a screensharing with another user and everything works fine on his computer. I don’t know what he did before.


1 Like

Do a “tccutil reset AppleEvents” in Terminal.
Start version 6.1.3 of my app. Get mailboxes from Mail: everything is okay.
Do a “tccutil reset AppleEvents” in Terminal.
Start version 6.2 of my app. Get mailboxes from Mail: no dice.

If there is no NSAppleEventsUsageDescription then I get the same result -1643 “don’t wanna” instead of asking for the permissions.

I don’t have a plist file but do everything in an IDE script with localisation:

command = "/bin/echo 'NSAppleEventsUsageDescription = ""Mail Archiver uses AppleScript to communicate with Mail and Outlook, Filemaker.""; '>>" + appPath + "/Contents/Resources/en.lproj/InfoPlist.strings" Call DoShellCommand(command)

The strings are in the plist where they should be.

Why does the app get the NSAppleEventsUsageDescription in debug and after building but not in the notarized dmg?

I can reproduce the behaviour. If I pack and notarise a test app with AppWrapper then AppleScript doesn’t work. App is available at .

@Sam_Rowlands : bug in AppWrapper?

There are indeed no privacy usage strings in your test applications plist. I don’t think it is a bug with App Wrapper as App Wrapper also uses them (you can check the App Wrapper plist file if you like).

I am a bit confused, you say you don’t use a plist, but then say they’re in the plist. AFAICT that command line snippet processes the localized version of the strings and NOT the actual plist.

I think I need more information for this.

Start by building a version of your application, ensuring the keys are in the plist file. Then drag that application to App Wrapper to process it, once the wrapped version of the application and check the plist. Notarize it and then check the plist of the Notarized version.

Otherwise please send me a copy of the unwrapped application and your App Wrapper data file, so I can attempt to reproduce it here.

I add the information for the plist with an IDE script. Because of the localisation the information is not in the plist but in the locale files:

I’ve sent you the test project and the AppWrapper file.

Probably this is my stupidity - as usual. In version 6.1.3 I’m using an entitlements file:

AppWrapper doesn’t have an extra entitlement for AppleScript. Instead it has the following section:

My guess is that the switch does the entitlement.

I hate Apple security.

Correct. The field “Usage string” is also where you add the “Default” usage string.


  • I can confirm that your project built with 2021r1, works in debug while unsigned and not including the Usage strings in the actual plist file. I did have to replace the MBS AppleScript code with OAK AppleScript code.
  • Wrapped with App Wrapper, using your App Wrapper file, it continues to work.
  • Unselected the option in the “Automation” section of “Security & Privacy” and it gives me the error message “Not Authorized”.
  • Using your commandline function to reset TCCs does indeed make the application return “Not Authorized”.
  • Firing up “Find Any File” asks me to Authorize it.
  • Attempting to use AppleScript from App Wrapper also asks me to authorize it.
  • Success - Enabling AppleScript in the Capabilities pane of App Wrapper and setting a Usage string “Mail Archiver X can then access mail in Apple Mail and others”. Then asked me to authorize when I re-opened your demo application.

So it appears that Apple have different rules for unsigned applications and signed applications, which quit frankly is not surprising as they’re about as well organized as I am (which is not).

I got the test app working fine with AppleScript. The final app does NOT work. Does AppWrapper propagate the AppleScript entitlement to helper apps?

I see, so the AppleScript is being called from a Helper. Is the helper being launched by the main application or another application, say the commandline or a something?

Is the final application for the Mac App Store or website deployment?

Click on the “Options” button next to “Code signing” in the sidebar and check the "Nested executable entitlements popup menu.

  • Default - Will pick what App Wrapper understands to be the best method. With the App Sandbox, it uses “Inheritance Plus” otherwise “main”.
  • Inheritance Plus - Uses Inherited Entitlements, as well as including certain entitlements for Hardened Runtime.
  • Inheritance - Uses Inherited Entitlements for nested executables.
  • Main Entitlements - Uses the exact same entitlements for the main application and nested components.
  • None - I don’t recall why this was added.

What is the difference between Inheritance, Inheritance Plus and Main Entitlements? Isn’t Main and Inheritance the same?

Both Main and Inheritance plus don’t work. What now?

The “Helper” app is an app that is installed by a self written installer. No commandline. The final app is for website deployment.

AppWrapper is overwriting the existing entitlements. In the old version of my app I used an entitlement plist file and did the codesign in code. The current version should use only AppWrapper for codesigning, creating the dmg and notarisation. But I forgot to take out the codesign.

I just did a test where I built the app and then only used “Pack & Notarise” instead of “Wrap, Pack & Notarise” and I finally got the automation correct. Now the path of the second app in the dmg is wrong but at least I’m making progress.

How can I script AppWrapper not to do a codesign? Using “Wrap, Pack & Notarise” fubars the Automation security even with "“Nested executable entitlements” set to none.

If necessary I can do my app in 2 steps for a while.