Can only run AppleScript from Automator

Question

I have the following AppleScript which toggles the scroll direction on the trackpad:

tell application "System Preferences"
    activate
    set current pane to pane "com.apple.preference.trackpad"
end tell

tell application "System Events"
    tell process "System Preferences"
        click radio button "Scroll & Zoom" of tab group 1 of window "Trackpad"
        click checkbox 1 of tab group 1 of window "Trackpad"
    end tell
end tell

tell application "System Preferences"
    quit
end tell

This script runs without issues when the "play" button in Automator is used to execute it. However, when I make a service that runs it and assigned a keyboard shortcut to the service, it fails to run via the keyboard shortcut.

Wrapping it in a try block with some error reporting yields the following:

Automator Runner is not allowed assistive access.

Error number-1728

I found Automator Runner.app and gave it assistive access using the instructions found here.

It now appears with a checked box in the list of applications with assistive access:

However, the issue persists. I continue to get the same message notifying me that Automator Runner is not allowed assistive access. when trying to run the script using the keyboard command of the service that runs the script.

---

Update

I just succeeded at implementing this alternative script to accomplish the same thing, but it also only works when Automator has focus and has the same issue when it does not:

tell application "System Preferences"
    reveal anchor "trackpadTab" of pane "com.apple.preference.trackpad"
end tell
tell application "System Events" to tell process "System Preferences"
    click checkbox 1 of tab group 1 of window 1
end tell
quit application "System Preferences"

Answer 1

Important note regarding AppleScript actions in Automator workflows.
Hopefully this helps others who are looking for a fix.

Assistive Access

If your script uses things like tell application "System Events" to get UI data from app windows or send virtual keystrokes, etc, then it'll require "assistive access".

This may be called different things in different versions of Mac OS, but can generally be found in System Preferences > Security & Privacy > Privacy > Accessibility, under "Allow the apps below to control your computer".

Enabling assistive access for the Automator and Script Editor applications will allow your workflows and scripts to run from those tools, but not when saved as standalone apps. In theory, enabling access for any app should also let it talk to System Events.

Problem with AppleScripts run from Automator Actions

But as many have discovered, Automator often has issues creating apps that can be granted assistive access, when such apps contain AppleScript code. Not to mention the fact that services cannot be granted such permissions at all, since they aren't apps.

Workaround

However, you can build standalone AppleScript apps from the Script Editor application instead, and grant them assistive access without issue.

You can then run such apps as part of an Automator or shell workflow, like this:

AppleScript action in Automator

do shell script "osascript -e 'tell application \"My Granted App Name\" to activate'"

Shell Script
(can also be from an Automator action)

osascript -e 'tell application "My Granted App Name" to activate'

This also works for creating services in Automator. Just have your service run the permission-granted app, rather than trying to add permission-requiring code to the service itself.

Note that the tell app call doesn't require the ".app" extension, or even a path. If you have many apps with the same name, there should be a way to get the app by its bundle identifier, etc.

Other IDEs

I'm not sure if this is a problem specific to Automator, since I haven't tried calling fancy AppleScripts from apps built with tools other than that and Script Editor. Either way, the above should work for other IDEs/compilers/etc. as well.

Re-Building your App

In most cases, editing and re-building a granted app requires it be re-granted access. So it helps to test everything well in Automator/Script Editor before you build the standalone app, to save you the trouble. If your script is called by a larger project you routinely recompile, it's best to turn that script into its own app to grant it access once, and run the app from your larger project. At least until the larger project is finalized.

For apps used by multiple scripts, you could keep them in a consistent spot like a custom /Applications/Tools/Scripts folder. However, remember that any third-party code can launch apps and thus activate your potentially sensitive scripts. It's important to consider security implications when creating code that using assistive access.

When Re-Granting Doesn't Work

There are times when re-granting a rebuilt app doesn't "take". In such cases, renaming the app and re-adding it via System Preferences usually solves this. You should be able to re-name the app back to its original at a later time. This is a bug with how Assistive Access caches its list of apps, and the filename and/or path are involved somehow. If anyone knows how to clear this cache, please add a comment; it would be very helpful.

Answer 2

I suspect you may not really have a problem that could be "debugged".
Read this Guide from macosxautomation.com on how to have applets that don't permanently keep their "permission" to run, be accepted by Mac OS X.

Trick is to install a special ResourceRules-ignoring-Scripts.plist that you sign and register your app(let) into. (But read the WARNING on this web page!)

Reason is, some apps save information "into themselves" and therefore won't be identical/ recognized next time they run.

(But anyway: even if the Guide's advice does NOT help you, it still might be of interest to others ...)

Answer 3

I know this is an old question, but I was facing this issue just now and I managed to work around it, so I thought I would post an answer.

I'd read elsewhere that adding Automator Runner.app to the Privacy/Accessibility pane of System Preferences would not prevent the error, so I didn't try it, but what did work for me was pasting the entire workflow into a new "Application" workflow document. I saved that in the same location as the service and then I created a new "Service" workflow that only did 1 thing: run the new application I had just created.

I then added that application to the Privacy/Accessibility pane of System Preferences. Now, when I run the service, I do not get the permissions error.

Answer 4

Not an answer, but...
To attempt to debug, I would deconstruct the script to its components, so roughly split to only

tell application "System Preferences"
activate
set current pane to pane "com.apple.preference.trackpad"
end tell

& test for any error

Then add

tell application "System Events"
    tell process "System Preferences"
         click radio button "Scroll & Zoom" of tab group 1 of window "Trackpad"
    end tell
end tell

check again

& onward until you find the fail point

One possibility would be to reverse sys events & sys prefs in your current running order, but that's just a shot in the dark.

Hopefully, someone with better applescript chops than I will provide a better solution.

Answer 5

When working on https://apple.stackexchange.com/a/436069/53510, I ran into this problem.

For me, the (partial, imperfect) solution seems to be:

1. System Preferences > Security & Privacy > Privacy > Accessibility
2. Add your most frequently-used apps (the ones that are likely to be active and "focused" on when you're pressing the keyboard shortcut or otherwise triggering a Service.
3. Quit and re-open each of those apps.
4. Try triggering your Service again (such as via keyboard shortcut).
5. Notice where it gets blocked (such as in my case, the System Preferences window was opened but not visible, so I clicked the icon in the Dock)
6. See the dialog box asking for elevated permissions, and grant them.

Answer 6

I Found the Solution!!! I found the best way to avoid this error is to use + sign and add application that way first. Then try run it. (I.e don’t try run it first. I.e. don’t drag and drop in there first.)

As a last resort fix: open system preferences. Remove the app with minus. Lock. Quit system preferences. Reopen system preferences. Add app with plus sign. Lock. Quit system preferences. Then try run app. Take your time with each of these steps...don't rush it. Still not working. You can mix in a restart and some log out log ins...it will eventually work...sounds like madness I know...but it works.

Monterey 12.4.

Thanks to SIMCC