Nota importante sobre las acciones de AppleScript en los flujos de trabajo de Automator.
Esperemos que esto ayude a otros que están buscando una solución.

Acceso asistido

Si su secuencia de comandos usa cosas como tell application "System Events"obtener datos de la interfaz de usuario de las ventanas de la aplicación o enviar pulsaciones de teclas virtuales, etc., entonces requerirá "acceso de asistencia".

Esto puede tener diferentes nombres en diferentes versiones de Mac OS, pero generalmente se puede encontrar en Preferencias del sistema> Seguridad y privacidad> Privacidad> Accesibilidad , en "Permitir que las aplicaciones a continuación controlen su computadora" .

Habilitar el acceso de asistencia para las aplicaciones Automator y Script Editor permitirá que sus flujos de trabajo y scripts se ejecuten desde esas herramientas, pero no cuando se guarden como aplicaciones independientes. En teoría, habilitar el acceso para cualquier aplicación también debería permitirle hablar con Eventos del sistema.

Problema con AppleScripts ejecutados desde Automator Actions

Pero como muchos han descubierto , Automator a menudo tiene problemas para crear aplicaciones a las que se les puede otorgar acceso de asistencia, cuando dichas aplicaciones contienen código AppleScript. Sin mencionar el hecho de que a los servicios no se les pueden otorgar tales permisos , ya que no son aplicaciones.

Solución alterna

Sin embargo, puede crear aplicaciones AppleScript independientes desde la aplicación Script Editor y otorgarles acceso de asistencia sin problemas.

Luego puede ejecutar dichas aplicaciones como parte de un flujo de trabajo de Automator o shell, como este:

Acción de AppleScript en Automator

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

Shell Script
(también puede ser de una acción de Automator)

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

Esto también funciona para crear servicios en Automator. Simplemente haga que su servicio ejecute la aplicación con permiso otorgado, en lugar de intentar agregar un código que requiere permiso al servicio en sí.

Tenga en cuenta que la tell appllamada no requiere la extensión ".app", ni siquiera una ruta. Si tiene muchas aplicaciones con el mismo nombre, debería haber una forma de obtener la aplicación por su identificador de paquete, etc.

Otros IDE

No estoy seguro de si este es un problema específico de Automator, ya que no he intentado llamar a AppleScripts sofisticados desde aplicaciones creadas con otras herramientas además de Script Editor. De cualquier manera, lo anterior debería funcionar para otros IDE/compiladores/etc. también.

Reconstruyendo su aplicación

En la mayoría de los casos, la edición y reconstrucción de una aplicación otorgada requiere que se le vuelva a otorgar acceso. Por lo tanto, es útil probar todo bien en Automator/Editor de secuencias de comandos antes de crear la aplicación independiente, para evitarle problemas. Si su secuencia de comandos es llamada por un proyecto más grande que vuelve a compilar de forma rutinaria, es mejor convertir esa secuencia de comandos en su propia aplicación para otorgarle acceso una vez y ejecutar la aplicación desde su proyecto más grande. Al menos hasta que se finalice el proyecto más grande.

Para las aplicaciones utilizadas por varios scripts, puede mantenerlas en un lugar uniforme, como una carpeta /Aplicaciones/Herramientas/Scripts personalizada . Sin embargo, recuerde que cualquier código de terceros puede iniciar aplicaciones y, por lo tanto, activar sus secuencias de comandos potencialmente confidenciales. Es importante tener en cuenta las implicaciones de seguridad al crear código que utiliza el acceso de asistencia.

Cuando volver a conceder no funciona

Hay momentos en los que volver a otorgar una aplicación reconstruida no "toma". En tales casos, cambiar el nombre de la aplicación y volver a agregarla a través de Preferencias del sistema generalmente resuelve esto. Debería poder cambiar el nombre de la aplicación a su original más adelante. Este es un error con la forma en que Assistive Access almacena en caché su lista de aplicaciones, y el nombre de archivo y/o la ruta están involucrados de alguna manera. Si alguien sabe cómo borrar este caché, agregue un comentario; sería muy útil.

Sospecho que es posible que realmente no tenga un problema que pueda ser "depurado".
Lea esta guía de macosxautomation.com sobre cómo tener applets que no mantengan permanentemente su "permiso" para ejecutarse, sean aceptados por Mac OS X.

El truco es instalar un ResourceRules-ignoring-Scripts.plist especial en el que inicie sesión y registre su aplicación (deje). (¡Pero lea la ADVERTENCIA en esta página web!)

La razón es que algunas aplicaciones guardan información "en sí mismas" y, por lo tanto, no serán idénticas ni reconocidas la próxima vez que se ejecuten.

(Pero de todos modos: incluso si los consejos de la Guía NO te ayudan , igual pueden ser de interés para otros...)

Sé que esta es una vieja pregunta, pero justo ahora me enfrentaba a este problema y logré solucionarlo, así que pensé en publicar una respuesta.

Había leído en otra parte que agregar Automator Runner.appal panel Privacidad/Accesibilidad de Preferencias del sistema no evitaría el error, así que no lo intenté, pero lo que funcionó para mí fue pegar todo el flujo de trabajo en un nuevo documento de flujo de trabajo de "Aplicación". Lo guardé en la misma ubicación que el servicio y luego creé un nuevo flujo de trabajo de "Servicio" que solo hizo 1 cosa: ejecutar la nueva aplicación que acababa de crear.

Luego agregué esa aplicación al panel de Privacidad/Accesibilidad de las Preferencias del Sistema. Ahora, cuando ejecuto el servicio, no obtengo el error de permisos.

No es una respuesta, pero...
Para intentar depurar, deconstruiría el script en sus componentes, por lo que dividiría aproximadamente solo

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

& prueba para cualquier error

Luego añade

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

revisar otra vez

y hacia adelante hasta que encuentre el punto de falla

Una posibilidad sería invertir los eventos del sistema y las preferencias del sistema en su orden de ejecución actual, pero eso es solo un tiro en la oscuridad.

Con suerte, alguien con mejores habilidades de applescript que yo proporcionará una mejor solución.

Cuando trabajaba en https://apple.stackexchange.com/a/436069/53510 , me encontré con este problema.

Para mí, la solución (parcial, imperfecta) parece ser:

1. Preferencias del sistema > Seguridad y privacidad > Privacidad > Accesibilidad
2. Agregue las aplicaciones que usa con más frecuencia (aquellas que probablemente estén activas y "enfocadas" cuando presione el atajo de teclado o active un Servicio).
3. Salga y vuelva a abrir cada una de esas aplicaciones.
4. Intente activar su Servicio nuevamente (por ejemplo, a través de un atajo de teclado).
5. Observe dónde se bloquea (como en mi caso, la ventana de Preferencias del sistema se abrió pero no estaba visible, así que hice clic en el ícono en el Dock)
6. Vea el cuadro de diálogo que solicita permisos elevados y concédalos.

¡¡¡Encontré la solución!!! Encontré que la mejor manera de evitar este error es usar el signo + y agregar la aplicación de esa manera primero. Luego intente ejecutarlo. (Es decir, no intente ejecutarlo primero. Es decir, no arrastre y suelte allí primero).

Como solución de último recurso: abra las preferencias del sistema. Eliminar la aplicación con menos. Cerrar con llave. Salga de las preferencias del sistema. Vuelva a abrir las preferencias del sistema. Agregar aplicación con signo más. Cerrar con llave. Salga de las preferencias del sistema. Luego intente ejecutar la aplicación. Tómese su tiempo con cada uno de estos pasos... no se apresure. Sigue sin funcionar. Puede mezclar un reinicio y algunos inicios de sesión de cierre de sesión ... eventualmente funcionará ... suena como una locura, lo sé ... pero funciona.

Monterrey 12.4.

Gracias a SIMCC