PUNCHCARD Download Get Punchcard $9

Automation permission on a Mac: what one app can do to another

· 6 min read

Automation permission lets one Mac app send commands to one other app, such as asking a browser for the address of the tab in front. macOS decides it per pair of apps, lists every decision in System Settings, Privacy & Security, Automation, and limits each grant to whatever the target app has made scriptable. That makes it narrower than Accessibility, but not trivial: control of a browser can reach a lot. Here is how it works, how to judge a request, and how to take it back.

What the permission covers

Under AppleScript sits a plainer mechanism called Apple Events: structured messages one app sends another, such as “get the URL of the active tab of window 1”, with a reply coming back. AppleScript is a language for writing them; apps can also send them from their own code.

Each scriptable app publishes a scripting dictionary, the list of objects and commands it accepts. Chrome, Brave, Edge and Vivaldi share Chromium’s, which includes windows, each window’s active tab, that tab’s URL and title, and a window mode that answers “normal” or “incognito”.

Automation permission is your consent for one app to send these events to another. It is not a general “control my Mac” switch but a list of pairs: this app may, or may not, command that app. It sits in the same pane as the permissions in what Mac apps can see about you, permission by permission, and works differently from all of them.

The prompt, one pair at a time

The first time an app tries to control another, macOS stops it and asks. The prompt names both apps, in the form “Punchcard wants access to control Google Chrome”. macOS adds its own warning that allowing control gives access to documents and data in the target app and lets the requesting app act within it. Then comes the developer’s reason, which every app must supply (a usage description). Read it: a vague reason is information.

Your answer covers that pair only. Allowing Punchcard to control Chrome says nothing about Punchcard controlling Brave, or Terminal controlling Chrome. Each pair gets its own prompt and its own switch. Once you answer, macOS does not ask again for that pair; a refused app simply gets an error.

How far it reaches: the target’s dictionary

Accessibility permission is system-wide: an app holding it can read the interface of every app and post clicks and keystrokes anywhere. Automation is one app at a time, and within that app it can do only what the app’s dictionary offers.

That can still be wide. A browser’s dictionary exposes what you are browsing; Finder’s can list and move files. To see exactly what a target offers, open Script Editor (in Applications, Utilities), choose File, Open Dictionary, and pick the app. That is the ceiling for any app that controls it.

System Events. A background part of macOS that scripts use to reach, among other things, the menus and buttons of other apps. That interface scripting also needs Accessibility, so an app holding both has close to the full reach of Accessibility. Treat a request to control System Events as a request for more than one app.

JavaScript inside browser pages. In Chrome, running JavaScript inside pages from AppleScript needs a separate switch, View, Developer, Allow JavaScript from Apple Events, which is off by default. With it off, a script can see which page is open but cannot run code inside it. Reading a tab’s address does not need it. Unless you write such scripts yourself, leave it off.

How to judge a request

  1. Does the reason match what the app does? A time tracker asking to control your browser so it can itemize websites is coherent. A wallpaper app asking the same is not.
  2. Is it only for the apps it names? An app asking to control a string of apps its reason never mentions is collecting reach.
  3. Did it ask when you used the feature? A prompt right after you pressed the related button is the healthy pattern; a burst of prompts at launch is not.
  4. What happens if you say no? When unsure, refuse. You can switch it on later, and a well-built app will say what stopped working.

Where to see it, switch it off, or start over

  1. Open System Settings and choose Privacy & Security.
  2. Open Automation.
  3. Each app that has asked is listed, with a switch for each app it asked to control. Turn off any pair you do not want.

A switched-off pair stays on record as no. To make macOS forget and ask afresh the next time the app tries, reset it in Terminal with the app’s bundle identifier:

tccutil reset AppleEvents app.punchcard.mac

That is Punchcard’s identifier. For any other app, osascript -e 'id of app "Google Chrome"' prints it (use that app’s name). Leaving the identifier off resets Automation for every app on the Mac, which is rarely what you want.

To watch the whole cycle, run this in Terminal (in Applications, Utilities) with Chrome open:

osascript -e 'tell application "Google Chrome" to get mode of window 1'

macOS asks whether Terminal may control Google Chrome. Allow it, and Terminal prints “normal” or “incognito” for Chrome’s front window. Terminal now has a Google Chrome switch in the Automation list; turn it off when you are done. For other browsers, use “Brave Browser”, “Microsoft Edge” or “Vivaldi”.

A worked example: Punchcard and your browser

Punchcard is a menu bar app that notices which app is in front during your day and prints a paper receipt of it at a closing time you set. Out of the box it records app names only and needs no macOS permissions: no Accessibility, no Screen Recording, no Full Disk Access. Its one optional permission is Automation, and only if you switch on “Itemize websites” in its Settings, so browser time prints as the sites you used instead of one browser line.

Against the questions above:

  • Only the apps it names. Chrome, Brave, Edge and Vivaldi, including their Beta, Dev, Canary and Nightly builds. macOS asks once per browser, so you can allow one and refuse another. Safari is not read, because its scripting cannot tell a Private window from a normal one; Firefox and Arc are not itemized either.
  • Only what the reason needs. Punchcard asks for the window’s mode first and requests the front tab’s address only when the browser answers “normal”. Incognito, InPrivate, Private and Guest windows are never asked for their address; that time stays on the browser’s own line (how to check a tracker yourself). It keeps only the site name (github.com), never the full address, search terms or page title.
  • Only when it matters. It checks the front tab every few seconds, only while a supported browser is the app in front and you are not idle. Chrome’s JavaScript switch can stay off.
  • Easy to take back. Settings shows each browser as Itemizing, Blocked (with a Fix in Settings button), Waiting for your OK, or Checks in when you open it. Turn “Itemize websites” off, switch off one browser in the Automation list, or use the tccutil line above.

What it does not do: tell you which page or document you were on, or itemize Safari, Firefox or Arc.

Questions

Is Automation the same as Accessibility?

No. Accessibility lets an app read and operate the interface of every app on your Mac. Automation is granted one pair of apps at a time and is limited to what the target’s scripting dictionary offers.

My script says it is not authorized to send Apple Events. What now?

That error (number -1743) means the pair was refused or switched off. Turn the switch on in the Automation list, or reset the app that runs the script with tccutil and run the script again to get the prompt.

Does switching Automation off break the app?

Only the feature that needed it. If you switch Punchcard off for Chrome, Chrome time prints as one Chrome line again, and the day total stays the same.