OK, I've moved on a bit... and would appreciate confirmation of my current understanding... The reason that terminal works is because this is enabled in Security & Privacy > Privacy > Automation > Terminal.app > System Events.app (checked). When the app is run via the terminal it inherits these rights, so all is fine and dandy. The only way to make this work when double clicking the app is to use a temporary exception entitlement: com.apple.security.temporary-exception.apple-events This is largely prohibited from the app store, which doesn't concern me, as I will be "out of App store". So I've taken my first round of the codesign, notarize dance: After creating my App ID, the Developer Certificate, and Provisioning Profile I then created an entitlements plist. Please see below. I then signed the app and notarized sucessfully. Note: I am not using XCode, but used the command line utilities. This did not fix the problem. My current thinking as to what may address the issue is: Set the Capabilities within the App ID. When I set this up, I couldn't see any that related to System Events, so currently no capabilities are enabled. What one(s), if any do I need to enable on the App ID to activate the System Events? I need to use the Provisioning Profile to "whitelist" the temporary exception. Is this required? I haven't found any instructions yet as to how to use the Provisioning Profile to white list the temporary exception. How do I do this? I've seen a reference to placing it in the MacOS directory, but not sure... I need to "Harden Up"!. I suspect this may be a prerequisite for enabling the temporary exception, but again I'm not sure. I believe there's a setting within XCode, but how do I "harden" manually, and at what stage do I do this? I'm missing some other entitlements. Please see the current ones below - are these all necessary and sufficient? I suspect that the network entitlements have worked, but how do I check that? There are no permissions within the Privacy panel. I understand that the user approved entitlements get stored in the TCC database, but the tccutil doesn't provide a way of listing these? I'd very much appreciate some pointers as to which avenues to take. Thanks, Stew <key>com.apple.security.cs.allow-unsigned-executable-memory</key><true/> <key>com.apple.security.cs.disable-library-validation</key><true/> <key>com.apple.security.cs.allow-dyld-environment-variables</key><true/> <key>com.apple.security.files.user-selected.read-write</key><true/>

Duh! It didn't like the Xml. Here are the entitlements: com.apple.security.automation.apple-events true com.apple.security.network.client true com.apple.security.network.server true com.apple.security.temporary-exception.apple-events true com.apple.security.cs.allow-unsigned-executable-memory true com.apple.security.cs.disable-library-validation true com.apple.security.cs.allow-dyld-environment-variables true com.apple.security.files.user-selected.read-write true

Sorry, I missed something that may be relevant. After the notarization had succeeded, as notified by email: Your Mac software has been notarized. You can now export this software and distribute it directly to users. I ran: spctl -a -vv MyApp.app       and got this: MyApp.app: a sealed resource is missing or invalid. Which could be another issue? What would cause this to fail, especially after the successful notification? I also mention "exporting" - presumably this is from XCode, or is there a manual step I also need to do? Cheers, Stew

Hi Quinn, Thanks for your reply and clarify my understanding regarding not needing entitlements for posting CGEvents. I think I was confusing this with AppleEvents. I do run scripts to raise windows, check if they're open, or minimised. As they work fine, can I safely assume that there are no security implications in doing this? Back to the posting events... I came across a post of yours which is relevant: Programmatically press "delete" or "cmd + v" in sandboxed app https://developer.apple.com/forums/thread/708652 T1Daniel presented a sample that "//Triggers system default accessibility access pop-up". I did a simple runtime test with a few keystrokes. I don't get a pop-up as expected, and also get a "Sender is prohibited from synthesizing events" in the Console for each key down/up post. Which leads me to the second part of your reply, where you may have hit the nail on the head! Yes, I am using a .sh script as the configured executable. The script sets the current directory to the "application" directory within Resources, and then executes the executable. This is on account of using a Pharo Smalltalk VM as the executable. Please see the script below. Reading your On File System Permissions post: TCC and Main Executables TCC expects its bundled clients — apps, app extensions, and so on — to use a native main executable. That is, it expects the CFBundleExecutable property to be the name of a Mach-O executable. If your product uses a script as its main executable, you are likely to encounter TCC problems. To resolve these, switch to using a Mach-O executable. Am I correct in thinking that this is the root cause of my problems? I guess I need to create a native main executable to implement the functionality of the script. Any suggestions as to the best way to do that? With respect to codesigning and notarization, I do need to do this as I want to avoid a nasty user experience when opening my app for the first time. See "Can't you just right click?" https://lapcatsoftware.com/articles/unsigned.html. So going down this rabbit hole has proved a valuable learning experience! Thanks for your help! Stew ============================= BASEDIR=$(cd $(dirname $0) && pwd) cd ${BASEDIR} cd ../ cd Resources/MyApp exec ../../MacOS/Pharo -logLevel=4 MyApp.image

Ok, after holding my nose with C I adapted your code to discover that changing the directory within this was useless, as it reverted once the trampoline process had finished. So I decided to simply invoke the Pharo VM directly. Due to some quirks/bus in its start up routines, it took many hours to get it to start and change the working directory. The good news is that I am now triggering the expected Accessibility prompt. As this is asynchronous, on installation I probe the system with a dummy keystroke, which causes the "Open Accessibility Preferences" dialog. I unlock, check the app, and re lock, and then continue. The bad news is that this makes no difference - Logic is not responding to the keypresses and I'm still getting the "Sender is prohibited from synthesizing events" in the Console error. Interestingly there's a whole bunch of messages in the Console when I'm configuring the accessibility. Some have red dots!. I did get a prompt for Automation/Apple Events when I first ran a script. This no longer appears, so at least that is working. There's a slight irony in your comment regarding "alternative development environments", since Apple software has its origins in Smalltalk. Please see https://www.mac-history.net/2010/03/22/apple-and-xerox-parc/2/ And your moniker triggered a tune that I recognised - good old Manfred Mann! Anyway, got any ideas on this? Cheers, Stew

Good news! I was about to do a reset using "sudo tccutil reset Accessibility" as described in https://www.macworld.com/article/347452/how-to-fix-macos-accessibility-permission-when-an-app-cant-be-enabled.html, and it suddenly started to work!. Not sure what I did differently, but as the article says, Accessibility is fragile. As I'm getting some "flashing" due to focus switching I'd like to explore the possibility of sending the events without having to bring Logic into focus. The OSC command that opens the Logic dialog, causes Logic to "bounce" in the dock. Is there any way I can send keyboard events to this bouncing, non focused dialog, without first bringing Logic into focus? If so happy to open a new thread to discuss. Thanks "Mighty Quinn"!

Please note that I've opened a new post regarding sending events without switching focus to avoid the flashing using CGEventPostToPid, which doesn't seem to work. See https://developer.apple.com/forums/thread/724835

I adapted the magic command referenced by: https://recoursive.com/2020/03/03/reset_macos_privacy_permissions/ on Monterey generate the list below. Hope this helps... strings /System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd | fgrep kTCCService | fgrep -v ' ' | sed -e s/kTCCService// | sort Accessibility AddressBook All AlwaysAllowedService.AppleEvents AppleEvents BluetoothAlways BluetoothPeripheral BluetoothWhileInUse Calendar Calls Camera ContactsFull ContactsLimited DeveloperTool ExposureNotification ExposureNotificationRegion FaceID Facebook FallDetection FileProviderDomain FileProviderPresence FocusStatus GameCenterFriends KeyboardNetwork LinkedIn ListenEvent Liverpool MSO MediaLibrary Microphone Motion NearbyInteraction Photos PhotosAdd PostEvent Prototype3Rights Prototype4Rights Reminders ScreenCapture SensorKitAmbientLightSensor SensorKitBedSensing SensorKitBedSensingWriting SensorKitDeviceUsage SensorKitElevation SensorKitFacialMetrics SensorKitForegroundAppCategory SensorKitKeyboardMetrics SensorKitLocationMetrics SensorKitMessageUsage SensorKitMotion SensorKitMotionHeartRate SensorKitOdometer SensorKitPedometer SensorKitPhoneUsage SensorKitSoundDetection SensorKitSpeechMetrics SensorKitStrideCalibration SensorKitWatchAmbientLightSensor SensorKitWatchFallStats SensorKitWatchForegroundAppCategory SensorKitWatchHeartRate SensorKitWatchMotion SensorKitWatchOnWristState SensorKitWatchPedometer SensorKitWatchSpeechMetrics ShareKit SinaWeibo Siri SpeechRecognition SystemPolicyAllFiles SystemPolicyDesktopFolder SystemPolicyDeveloperFiles SystemPolicyDocumentsFolder SystemPolicyDownloadsFolder SystemPolicyNetworkVolumes SystemPolicyRemovableVolumes SystemPolicySysAdminFiles TencentWeibo Twitter Ubiquity UserAvailability UserTracking WebKitIntelligentTrackingPrevention Willow

I've been getting to grips with TCC and have found the links below useful. I've yet to resort to the "nuclear" option of deleting the tcc database though! You could also try: sudo tccutil reset All com.vendor.appname https://eclecticlight.co/2018/11/20/what-does-the-tcc-compatibility-database-do/ https://www.rainforestqa.com/blog/macos-tcc-db-deep-dive https://recoursive.com/2020/03/03/reset_macos_privacy_permissions/ https://eclecticlight.co/2023/02/09/should-you-reset-its-database-or-delete-it-the-woes-of-tcc/ https://www.macworld.com/article/1378183/how-to-reset-macos-privacy-preferences-when-other-options-dont-work.html FYI to get a list of all the Services use this (works for Monterey, you may need to change the path): strings /System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd | fgrep kTCCService | fgrep -v ' ' | sed -e s/kTCCService// | sort

Answering my own question: It does this when the app hasn't been codesigned. Once code signed it shows as the app, not the launcher executable. Still don't now why though - one of life's little mystery's!

Thanks - that was exactly what was happening - all fixed now!

OK, I figured it out. For example: vtool -set-build-version macos 12.0 12.0 -replace -output "/Volumes/Data/Projects/MyApp/Pharo/Builds/1.0.0/Bundle/intel64/MyApp.app/Contents/MacOS/PluginsFixed/libUnixOSProcessPlugin.dylib" "/Volumes/Data/Projects/MyApp/Pharo/Builds/1.0.0/Bundle/intel64/MyApp.app/Contents/MacOS/Plugins/libUnixOSProcessPlugin.dylib" Unfortunately, I'm getting an error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/vtool error: mkstemp: No such file or directory I've created the output directory and confirmed I have the right path for the input file. I suspect this is a command line tools configuration problem when creating a temp file, and will create a new post. `vtool -help usage: vtool [-arch <arch>] ... <show_command> <file>     vtool [-arch <arch>] ... <set_command> ... [-replace] [-output <output>] <file>     vtool [-arch <arch>] ... <remove_command> ... [-output <output>] <file>     vtool -help  show_command is exactly one of:   -show   -show-build   -show-source   -show-space  set_command is one or more of:   -set-build-version <platform> <minos> <sdk> [-tool <tool> <version>] ...   -set-build-tool <platform> <tool> <version>   -set-version-min <platform> <minos> <sdk>   -set-source-version <version>  remove_command is one or more of:   -remove-build-version <platform>   -remove-build-tool <platform> <tool>   -remove-source-version  platform is one of:   macos   ios   watchos   tvos   bridgeos   maccatalyst   uikitformac   iossim   watchossim   driverkit  tool is one of:   clang   swift   ld  platform and tool can also be specified by number `

Hi Quinn, Yes, I have been reading and following your guidelines to the letter...they're most helpful - thanks. However I'm stuck with this workaround! I'm not using any CI Tools (apart from using Smalltalk scripts to run the Command Line tools directly). (Note, I get this problem when running manually from the command line). All the tools have worked fine so far (both on terminal and via script), apart from this instance. My setup is macOS 12.0.1 with Xcode 13.1. Yes, that's my conclusion as well, except I don't know how to configure the temporary directory for mkstemp/Command Line tools? Would I do this through Xcode, or some other environment variable? I guess if I new the directory it was trying to use, maybe I could just create it? I've checked the various $TMPDIR, and ~/Library/Caches and there are some com.apple.dt... files there, including Xcode. Or it could be permissions/space issue? This post https://stackoverflow.com/questions/16996125/no-usable-temporary-directory-found suggested running df -h and df -i. This doesn't seem to be an issue for me though. Thanks, Stew

Hi Quinn, Good news, and bad news - after building the dummy dylib and running vtool against it - it worked. Furthermore, when I reran vtool against my libraries, it worked too! I guess it must have set the temp path somehow? Another mystery! The bad news is that the library (which is not one that I've "fixed") still doesn't load when codesigned - it works fine without it. Back to reading your notes - I'll create another post after that... Thanks, Stew

FYI - please see https://developer.apple.com/forums//thread/726440?answerId=747919022#747919022 for the solution to the mkstemp error problem.