I haven't tried that. How do you reset the Launch Services cache? (I'm running Sonoma 14.3)
The commands are here:
https://discussions.apple.com/thread/251735453
Note that I don't know whether this will work in Sonoma, or even whether it is a good idea.
But since the issue is related to opening files in applications, the Launch Services cache might be involved, and it's been known to cause other problems over the years.
I too have this exact problem ever since macOS 14.3. Resetting the Launch Services cache did not fix it.
Resetting Launch Services also didn't work for me.
I have a report from a user with this problem that reinstalling the target application (removing it, rebooting, and then installing it), resolved the problem.
So that might be worth trying.
Here are a few more observations (and a workaround):
One factor seems to be the presence or absence of the quarantine bit:
- When I checked a few files for which "Open Finder selection with: BBEdit" resulted in "-128" errors, they all had the quarantine bit set.
- (FYI: If
xattr -p com.apple.quarantine /path/to/fileproduces any output other than "No such xattr: com.apple.quarantine", the quarantine bit is set for that file.) - After I removed the quarantine bit using
xattr -d com.apple.quarantine /path/to/file, the file worked normally again with the "Open Finder selection with: BBEdit" action.
The AppleScript @mrpasini posted above seemed to behave identically to the "Open Finder selection with: BBEdit" action, but only when executed via Keyboard Maestro. When I ran the script via Script Debugger or Script Editor, it worked fine on all files regardless of the presence of the quarantine bit.
Alfred's "Open with..." command also worked fine with all files.
If I use Keyboard Maestro's "Execute Shell Script" action with open -a "BBEdit" /path/to/file, the issue does not seem to be present. So as a workaround, I have now replaced my "Open Finder selection with: BBEdit" action with:
(Sonoma 14.3.1, Keyboard Maestro 11.0.2)
4 Likes
Just in case you weren't aware, you can install the BBEdit Command Line Tools (in the BBEdit menu in the app). Then you could just use the shell script bbedit "$KMVAR_Local_selectedFile".
No functional difference, but might be a thousandths of a hundredths of a nanosecond quicker :).
-rob.
Heh, that's true, @griffman. I actually do use bbdiff extensively myself. Since I have similar macros for other apps, too, I went for a universal approach, so they are all the same.
2 Likes
This issue has just kind of disappeared for me. I didn't take any troubleshooting steps. 
@Jack_Brannen, is is possible that you were only using the KM macro recently with files that didn't have the quarantine bit set (see my post above)? Because on both of my Macs, the issue is still reliably reproducible.
@NSSynapse Well, I spoke too soon. The issue is still occurring for me, but it's sporadic.
I just tested a file that worked, and the quarantine bit was not set—as you suspected. I'll test it again next time I find a file that doesn't work.
@peternlewis Is this something you may find a workaround for? Does the quarantine bit give you insight to change some code? Or is this a macOS limitation?
I too have had various scripts & automations fail in the latest Sonoma. Make sure to look in a few places to enable things under Privacy & Security - try "Accessibility", and "Automation", and also "Input Monitoring"
this apple security system is a disaster. the completely opaque interface, "xattr" nonsense, mess of a control panel, & especially the inane system where you get "one shot" to approve something...
/rant
there's nothing KM can do about the quarantine bit. MacOS sets it. Use this excellent tool to clear it: xattred, Spotcord, Metamer & xattr tools – The Eclectic Light Company
1 Like
It is macOS setting the bit, and then macOS refusing to do as it is requested when the bit is set, or to do anything useful instead.
You can clear the bit using the built in xattr shell tool.
xattr -d com.apple.quarantine path/to/file
Technically, obviously, Keyboard Maestro could simply actively clear the bit in the action, but I don't know that that is a good idea - this is an Apple system security feature (that works about as well as most of the rest of the Apple system security, which is that it stops bad things and also causes endless problems for everything else), and I don't know that Keyboard Maestro simply overriding it is something I should do.
But probably I should find a way to handle the error better.
I suppose a possible advantage of osascript -l JavaScript here is that the JS interface is late-binding in its Application references – we can supply an Application name string at run-time, rather than before compilation.
i.e. we can open a file with the Application reference, bypassing Standard Additions and (for the purposes of opening) Finder.
A rough illustration in the subroutine here:
Seems to work with, for example, Sonoma and current BBEdit builds.
1 Like
It seems I have something slightly different going on with a macro I've used for years with no problems until recently. It uses Open Finder Selection In and I get the two -128 error messages like many others. After Peter pointed me to this thread again (having forgotten that I posted previously—my Discourse settings will now keep me updated), I tried clearing the quarantine bit. xattr said there was none set, but for whatever reason, the app (a Retrobatch droplet) started working again.
However, it's failing again today in the same way with the two -128 dialogs. When I check the quarantine bit, it's still not set:
adam@2020-iMac ~ % xattr -l /Users/adam/Library/Mobile\ Documents/com\~apple\~CloudDocs/TidBITS/Tools/BorderMePro.app
com.apple.FinderInfo:
com.apple.fileprovider.fpfs#P:
And trying to clear it doesn't work:
adam@2020-iMac ~ % xattr -d com.apple.quarantine /Users/adam/Library/Mobile\ Documents/com\~apple\~CloudDocs/TidBITS/Tools/BorderMePro.app
xattr: /Users/adam/Library/Mobile Documents/com~apple~CloudDocs/TidBITS/Tools/BorderMePro.app: No such xattr: com.apple.quarantine
I can drop an image on the droplet manually and it works fine, so there has to be something related to how it's being launched by Keyboard Maestro.
Script Editor is fine -- but osascript from Terminal fails in the same way as the KM "Open Finder Selection" action, with the doubled -128 message.
Also, the first two of these actions fail but the third succeeds:
...and, IIRC, those first two also work via osascript. What about the third, @peternlewis? Perhaps osascript is the culprit?
The first two are essentially equivalent, they are using AppleScript to ask the finder to open the selection list.
The last one is quite different, it is using AppleScript to ask the finder for the selected file, and then using the system API to open the file (which presumably deals with the quarantine bit the way the Finder is supposed to, or maybe that's what Apple wants for the quarantine bit, to stop exactly this - who knows? I don't have any idea what Apple intends to be the behaviour of a file with this bit set).