A few who have upgrade to Mojave are finding apps which either don’t display the expected consent dialogs, or display them once and never again, so preventing them from giving that app access to protected data or services. Here’s what to do if you are having problems.

App Store apps

If you obtained the app from the Mac App Store, and it doesn’t seem to be handling the new privacy protection properly, an important first step is to check that it has the correct entitlements and usage information. You can do this using my free app Taccy, from Downloads above.

App Store apps are locked down in their Sandbox, and only allowed to do what they have requested in entitlements, which are baked into their signature. If an App Store app wants to be able to control other apps using AppleEvents or AppleScript, then it needs a com.apple.security.automation.apple-events entitlement. At present, Taccy doesn’t show this in the checkboxes (I will be adding it soon), but you should find it listed in the text in the scrolling view below.

In addition to the appropriate entitlement, the app also needs a usage string, which is shown in Taccy’s checkboxes. This is the text displayed after the standard wording in the consent dialog. This is only required when the app has been built against the 10.14 SDK, which is also shown in Taccy’s checkboxes.

If the app lacks the entitlement, then it will never be able to prompt you for your consent. There is nothing that you can do about that, unless you want to give it Full Disk Access by adding it to that privacy list, if that is an appropriate workaround. You can also add apps to the Accessibility list yourself. That won’t help you, though, if the app needs to be in the Automation, Location, Camera, or Microphone lists.

If the app lacks the usage string but was built against the 10.14 SDK, then trying to access protected data may cause it to unexpectedly quit. At the very least, expect it to result in an error.

You cannot add it to a list, other than Full Disk Access or Accessibility over which you have control. If you can’t get the app to display the consent dialog, then you should report this fault to its developer, who will almost certainly need to build a new and corrected version of the app to fix it.

Notarized apps

Although Notarization isn’t the same as the limits imposed by the App Store, with respect to privacy controls, it behaves very similarly. The app can only have been built against the 10.14 SDK (notarization isn’t available to apps built using Xcode 9 against the 10.13 SDK), so it will need both the appropriate entitlement and the usage string, as shown in Taccy.

The good news is that a developer who has got this wrong can fix it much more quickly: all they need to do is make the correction, rebuild the app, and submit it for notarization. The latter usually takes but a few minutes to complete, so a fixed version of the app should be in your hands very shortly.

Regular signed apps built against the 10.14 SDK

Entitlements don’t normally apply to apps which are neither notarized nor distributed through the App Store, although in theory a developer can ‘harden’ an app and impose entitlements without getting it notarized. I haven’t come across anyone doing that yet.

When built against the 10.14 SDK, an app must have the appropriate usage string, which you can check using Taccy.

If the app has the correct usage string, then when it tries to access protected data or services, you should be prompted to give your consent. If that doesn’t happen, it suggests a bug somewhere between the app and macOS, and you need to report the problem to its developer. If this is a matter of accessing protected data, you can add the app to the Full Disk Access list yourself, although that may give it broader access than you really want, and you control Accessibility too.

Regular signed apps built against an earlier SDK, such as 10.13

These don’t have entitlements or any requirement for usage strings, so should always display the consent dialog. If they don’t, report this to the developer, and add them to Full Disk Access or Accessibility list if that works around the problem.

Your own AppleScript and similar apps

If made using macOS 10.13 or earlier, these should behave like apps built against an older SDK. If they don’t, then open them using Mojave’s Script Editor and compile them again. If that won’t help, and you have an Apple developer certificate, then you may find that signing them helps them to work properly, although that shouldn’t be required.

You have previously refused consent

Mojave’s privacy system, TCC, doesn’t keep a blacklist of apps for which access to protected data has been refused, by clicking on the Don’t Allow button in the consent dialog. If you make an error, or change your mind, running the app again should result in exactly the same dialog, which you can then accept.

In fact, TCC tries to make this even easier. Let’s say that you saw this dialog and clicked on Don’t Allow. If you then open the Privacy tab of the Security & Privacy pane, and select the appropriate list at the left, you’ll see that TCC has already added that app, but left it unchecked.

Quit the app, click on the padlock in the pane and authenticate, then tick that checkbox. This should enable the app to access the protected data without any further dialogs, although you might find that you are prompted one last time, in which case you can click on OK as you had intended.

This applies not only to the Automation list, but also to narrower classes of data, such as Calendars here.

If you can’t get this to work as shown here, then try uninstalling the app with all its components (helper tools, etc.), restarting your Mac, downloading the latest release, and installing that. If that fails too, contact the developer.

Thanks to Michael Tsai for raising one of the problems considered here.