AMIs stopped working on OSX Monterey


my AMIs worked just fine early last year when I last needed them on my OSX machine (been in windows and linux land ever since).
But now they just don’t firfe the script that the protocol handler is poiting to (the app that was made from the simple Apple Script as per these docs).

When I try to run an AMI I can see for a split second that the applet is run, so the issue seems to be that it will not fire the assigned python script which lives on the server.
The python script uses the boiler plate and should at the least output some log info, but I get nothing.

I gave the applet full disk access in the system preferences as well:

The only thing that has changed is that I updated OSX to Monterey at some stage so I assume that might be related. There are a fair bunch of messages in the system console when I try to run the AMI but none of those mean anythign to me.

Does anybody have any ideas how to get this going again? AMIs are quite important to me.


1 Like

You better post the error messages. Possibly Python got updated? (no experience on OSX)

This is the error message I see in Apple’s Console when I try to run the AMI:
RBSStateCapture remove item called for untracked item 268-143-1744608 (target:[app<>:42252])

Followed by a ton of messages (not tagged as errors).

Support told me to updated my plist (see below), but it’s still not working, though I now get this message when I try to run the AMI:

Please follow the below for the Monterey update and let us know if have any issues.

The info. plist has changed. The following lines need to be deleted.

	<string>This script needs to control other applications to run.</string>
	<string>This script needs access to your music to run.</string>
	<string>This script needs access to your calendars to run.</string>
	<string>This script needs access to your camera to run.</string>
	<string>This script needs access to your contacts to run.</string>
	<string>This script needs access to your HomeKit Home to run.</string>
	<string>This script needs access to your microphone to run.</string>
	<string>This script needs access to your photos to run.</string>
	<string>This script needs access to your reminders to run.</string>
	<string>This script needs access to Siri to run.</string> 

The above lines are between

“NSAppleEventsUsageDescription” and “NSSystemAdministrationUsageDescription”

I long for the day that Apple is no longer part of our machine setup…

1 Like

Frank! Man… it’s been a long time… :slight_smile:

Long shot, but have you tried double clicking that applet on it’s own? It’s (remotely) possible it will register something that will allow it to run and then be accessible via your AMIs afterward. I’m not using that setup but I have encountered similar situations.

Don’t be a MacOS hater… ha.


1 Like

KP!! So good to see you are still hanging out here. I seriously miss you guys!
Hope you are well!!

I found the issue. Looks like the OSX upgrade lost /usr/bin/python . When I change the shebank in my AMI script to /usr/bin/python3 it actually runs as expected.
Makes sense and I should have checked that before.

Looks like the boiler plate never made it to python 3 though and I clearly forgot that my AMIs were still using Python2, so will look into patching that now.
EDIT: looks like it just needed one mod:

urllib.unquote > urllib.parse.unquote

Woopwoop, got my AMIs back, hooray.



I am trying but Apple is making it every hard not to with crap like this:

mmyeah python 2.7 has been end of life for 12 years man, update your version now :slight_smile:

And do you know when the vfx industry finally switched to python3?

I know some software lags behind ,but the reference platform for 2020 uses python 3.7.

I hear you Frank. We are uh… almost done switching :wink:

1 Like

One thing I found helped when trying to get the AMI to work on MacOS was to add a try ... on error errStr to the apple script to capture the error coming from the execution of the python script.

on open location this_URL
		do shell script " '" & this_URL & "'"
	on error errStr
		display dialog "error" & errStr
end open location

Very good point Philip, thanks. I was so busy wrestling with the protocol handler part that I wasn’t even thinking about putting that sort of sanity check in there.
All working now, I just need to suppress this annoying “Press tun to run this script?” dialog somehow that never used to pop up before…

Apple are constantly messing with the security settings on Mac OS so you are likely running into some new security warning.

Yes, I am very, very, very tired of Apple

1 Like

Finally got an updated plist from support that fixed it. Lots of info lost in communication with Autodesk Support these days. I guess that is what you get for using an Indian call centre instead of actual product specialists.