bertg

@Andrew Thanks for this info. I hadn't thought of checking the Alfred workflows. And lo-and-behold, I found it. There is a workflow that has that key-combo set. (The hotkeys.firedev.com package) So in this case Alfred could have known So yeah, i think the latest change you described let this issue bubble to the top. I've deleted the package (as I don't like key combo's anyway) and the lock functionality is working fine again.

@Andrew This indeed seems to be the case. It is a bit surprising that a changed keyboard shortcut changes the behaviour of Alfred. I would recommend changing it back; or giving the user feedback that the shortcut doesn't do what it says it would do. In a related question. I have no clue what or how this change came to be. Is there a way I could figure out which app/setting is doing this? The app in question has no customisable Keyboard shortcuts, so I doubt it is causing it. Or is there a way I can restore the default behaviour?

* What you were doing when the issue happened Nothing special, just trying to lock the computer. * Whether you were able to replicate it a second time by performing the same action Yes, Restarting Alfred or "Clear application Cache" do not change the behaviour. Changing the command name, or requiring Confirmation does not change the behaviour. (With confirmation, the dialogue does show up) Changing the apps name, does stop the app from opening, but still does not lock the device. Changing the name back restores the unwanted behaviour. * Include any screenshots that might help us I can share a screen recording if that is desired. * Include the Alfred version & build number you are using v3.6 [903] * Include your OS X version 10.13.3 (17D102)

Hi, I really love this script. But it seems somewhat overcomplicated. Instead of doing all the complex things with apple script etc... why not just use this: ```bash open "zoommtg://zoom.us/join?action=join&confno={query}" ```