itabraham

Here is console output filtered by the word "alfred" for the case with Secure Keyboard Entry enabled. error 13:02:48.192482-0500 WindowServer CPS: Denying Alfred the right to be in front because secureTextInput is active and this process doesn't have secure text mode enabled, and this request was not caused by user activity default 13:02:48.192291-0500 Alfred SetFrontProcess: asn=0x0-0x18e18e options=1 default 13:02:48.198900-0500 Alfred SetFrontProcess: asn=0x0-0x18e18e options=1 error 13:02:48.199006-0500 WindowServer CPS: Denying Alfred the right to be in front because secureTextInput is active and this process doesn't have secure text mode enabled, and this request was not caused by user activity default 13:02:48.212418-0500 runningboardd Acquiring assertion targeting [app<application.com.runningwithcrayons.Alfred.86238920.86238961(501)>:2415] from originator [daemon<com.apple.WindowServer(88)>:151] with description <RBSAssertionDescriptor| "AppDrawing" ID:166-151-14073 target:2415 attributes:[ <RBSDomainAttribute| domain:"com.apple.appnap" name:"AppDrawing" sourceEnvironment:"(null)">, <RBSAcquisitionCompletionAttribute| policy:AfterApplication> ]> default 13:02:48.212544-0500 runningboardd Assertion 166-151-14073 (target:[app<application.com.runningwithcrayons.Alfred.86238920.86238961(501)>:2415]) will be created as active default 13:02:48.213087-0500 runningboardd [app<application.com.runningwithcrayons.Alfred.86238920.86238961(501)>:2415] Ignoring jetsam update because this process is not memory-managed default 13:02:48.213115-0500 runningboardd [app<application.com.runningwithcrayons.Alfred.86238920.86238961(501)>:2415] Ignoring suspend because this process is not lifecycle managed default 13:02:48.213093-0500 runningboardd Calculated state for app<application.com.runningwithcrayons.Alfred.86238920.86238961(501)>: running-active (role: UserInteractive) default 13:02:48.213141-0500 runningboardd [app<application.com.runningwithcrayons.Alfred.86238920.86238961(501)>:2415] Ignoring GPU update because this process is not GPU managed

@Vero For me, the offending setting was Secure Keyboard entry. When I turned this off in both from Terminal > Secure Keyboard Entry as well as iTerm 2 > Secure Keyboard Entry, Alfred's Launcher behavior was restored to normal. Hope this tidbit of information helps. Credit goes to iTerm 2 developers for pointing out that this could be the issue. I had posted this over there as well because I wasn't sure the bug was on Alfred's end or iTerms end. With regards to the vanilla account, it is possible that this setting is turned off my default for the vanilla user account. Given that the purpose of Secure Keyboard Entry is to prevent key-logging, this mechanism is probably interfering with Alfred's ability to launch. Why this was not an issue in Catalina, I do not know; but the context seems similar (vis-a-vis, losing Alfred after clicking a password box). Probably Monterey upgraded/updated security.

Yes. In a newly created vanilla user account, the Alfred launcher does behave as expected (though, I should point out that is plain Alfred, i.e. without the Powerpack License in use in my usual user account).

A similar behavior has been happening for me since I upgraded to MacOS Monterey. However, I don't have issues with password fields, it is actually with two apps, iTerm 2 and the default Terminal app. I made a screen recording here. As per the standard bug reporting requirements: What you were doing when the issue happened: Updated to MacOS Monterey and was trying to open the Alfred Launcher while an iTerm 2 window was open and active. Whether you were able to replicate it: Yes. Repeatedly. Include any screenshots that might help us: Twitter link above. Include the version and build number from Alfred's General preferences (Don't say "latest", please be specific) Alfred 4.6 [1266] Include the version and build number from macOS and any apps that are relevant to the issue you're seeing MacOS Monterey 12.0.1. The problem affects Alfred when iTerm 2 or Terminal is open. However similar terminal apps like kitty and Hyper.is do not seem to cause issues. The problem can be resolved by manually clicking “Toggle Alfred” from the menu bar after quitting the offending application at which point, launcher operation resumes behaving as normal. Following the instructions above, I can confirm there are no issues on a vanilla user account. However leaving only Alfred on accessibility setting didn't seem to help matters.