Automation on a Mac: when one app wants to control another

Apple's steps for Automation are the same on macOS 14 Sonoma, macOS 15 Sequoia, macOS 26 Tahoe and macOS 27. One thing changed in macOS 15, for Finder; it's covered below.

What the prompt means

Many Mac apps can be controlled by other apps. Apple calls them scriptable: they make their operations and data available in response to messages called Apple events. AppleScript, scripts you run in Terminal, launchers and all sorts of utilities use Apple events to get things done in another app without you opening it yourself. Apple's own example is an app that uses Reminders to set up a reminder about a calendar event.

Because that reaches into another app, macOS asks you first, the first time an app tries. On a Mac running macOS 26, the request names both apps and says that allowing control will provide access to documents and data in the second app, and lets the first one perform actions within it. Under that is the requesting app's own reason, written by its developer; Apple's developer documentation describes it as a message that tells people why the app wants to send Apple events.

• Allow lets the app control that one other app.
• Don't Allow refuses. The app carries on, but it can't control that app, and macOS doesn't ask again.

The app named first is the one asking. If you run a script in Terminal or Script Editor, that's Terminal or Script Editor, not the script.

One switch for each pair of apps

Automation isn't one permission per app, like Accessibility. It's granted one pair of apps at a time: allowing a launcher to control Safari doesn't let it control Mail. If the same app later wants Mail too, macOS asks again, for Mail.

System Settings mirrors that. Under Privacy & Security › Automation, each app that has asked is listed with a switch for every app it asked to control. An app only appears there after it has asked: there's no Add button, unlike the Accessibility list.

The list also tells you what an app has been up to. An app you don't remember allowing, or one listed with an app you wouldn't expect it to need, is worth a second look.

Change your answer

1. Open Automation

   Choose Apple menu › System Settings, click Privacy & Security in the sidebar, then click Automation. You may need to scroll down. Apple's macOS 14 guide says to click Automation “on the right”; it's the same place.

2. Find the app

   Look for the app that asked, not the one it wants to control.

3. Turn the switch on or off

   Each switch under the app is one app it may or may not control. Turning one off blocks only that pair.

Once you've answered, this switch is where your answer lives. An app's own Allow button can only bring up macOS's request, and macOS shows that request just once per pair.

Ask again from scratch

To make macOS forget an app's Automation answers and ask again, use tccutil in Terminal with the service name AppleEvents and the app's bundle ID:

tccutil reset AppleEvents com.apple.Terminal

That clears every Automation answer the app has, for all the apps it asked about; tccutil can't clear one pair on its own. The app then asks again, one app at a time, as it needs them. Leave out the bundle ID and every app's Automation answers are cleared, so keep it in. Finding a bundle ID and the other service names: how to reset privacy permissions with tccutil.

Should you allow it?

Allowing gives more than it sounds. Apple's developer documentation uses Mail as the example: other apps can't read Mail's local data directly, but because Mail can be controlled with Apple events, an app allowed to control Mail can reach that data through it. So weigh it like this:

• Allow when you've just asked the app to do something with the other app, such as running a script that tidies Finder windows or a command that searches your browser tabs, and you trust its developer.
• Think twice when the request comes out of nowhere, or the reason line doesn't explain why this app needs that one.
• Read the privacy policy. Apple's guide points out that what an app collects this way is governed by the app's terms and privacy policy, not Apple's.

Saying no is low-risk: the app just can't control that one app, and you can turn the switch on later. Automation is also separate from the permissions that let an app record your screen, watch your keyboard or operate other apps' windows directly: those are Screen Recording, Input Monitoring and Accessibility (what the Accessibility permission allows).

With Flick

Flick, the window switcher we make, uses Automation for one thing: browser tabs, which come with a license. Switching windows needs only Accessibility. Every browser starts off, and macOS asks once for each browser you turn on in Flick's Settings › Browser Tabs: Safari, Google Chrome, Google Chrome Beta, Brave Browser or Microsoft Edge. It never asks during setup, and never because Flick read or switched a tab.

• A browser that isn't open is asked about the next time you open it while Flick is running.
• Safari is read only while Include private windows is on, so that's when macOS asks about Safari.
• The reason in the request is Flick's, word for word: “Flick reads the titles and addresses of your open tabs so you can search them and switch straight to one. Nothing leaves your Mac.”

Said Don't Allow? Settings › Browser Tabs shows a note under that browser with Open Privacy Settings. To start over, run tccutil reset AppleEvents com.flicknav.flick, then click Allow… next to each browser.

Allow Flick to control a browser · Browser tabs in Flick