Solution 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.

Solution 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 ...)

Solution 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.