skhd: skhd aborting because of false secure keyboard entry error

I had the same issue, and it was the loginwindow console process that caused it. I just locked my screen, and logged in again - that fixed the issue.

This oneliner works. Broke it up into multiple lines to make it easier to read.

ioreg -l -w 0 \
    | perl -nle 'print $1 if /"kCGSSessionSecureInputPID"=(\d+)/' \
    | uniq \
    | xargs -I{} ps -p {} -o comm=

Edit: Updated to make it much easier to read and also work with multiple different sources of secure keyboard input.

In my case it was loginwindow console process (So I killed it with my whole user session 😆 I do not recommend this).

Not sure if this still works, but I came across this:

peternlewisElderDec '15
Thanks to info provided by the fine folks at Smile Software 24, you can use the Terminal command:

ioreg -l -w 0 | grep SecureInput
That will tell you the process ID (kCGSSessionSecureInputPID) of the application that has Secure Input enabled. You can then use:

ps auxww | grep NNN
to find the process with the specified pid.

I will endeavour to add some support for this within Keyboard Maestro’s alert in the future.

Thanks again to the Smile Software 24, makers of great Mac software!

Source: https://forum.keyboardmaestro.com/t/disable-secure-input/2410/3

I had this issue with kitty as several others here too. And I have found the reason and solution to fix this once and for all! 🎉 Well, at least for those where kitty was the culprit of course.

It’s in fact a sensible kitty feature, with an annoyingly bad default shortcut, that can be easily hit by accident:

cmd+opt+s: toggle_macos_secure_keyboard_entry

Pressing this I can consistently recreate the issue.

The state persists even with reboots - which is probably a smart thing to do on kitty’s part, given the purpose of the toggle. The default shortcut is just astoundingly bad (and a visual indicator might be helpful too).

I immediately disabled it:

# ~/.config/kitty/kitty.conf
map cmd+opt+s noop

Note: there’s a PR making the remap possible earlier this year. It has been merged - but if remapping ain’t working, check your kitty version

1. Accordingly, I’ll lock and unlock my screen, and now the script shows the terminal I’m using to start skhd (kitty, alacritty, Terminal.app…) as the culprit.

This happens to me too

I need to do further testing, but it seems like the problem might have come from the Bitwarden app; I closed it and the issue was no more.

Same here ! Closing Bitwarden definitely solved the issue, I couldn’t restart / start skhd in any way before that.

Thanks for figuring it out @augustebaum

I’m just seeing your advice, thanks. By brute force, I think I’ve determined it was Keybase.app. After almost a week I finally have skhd back! 🎉

For what it’s worth, although the loginwindow issue happens to me all the time (maybe 50-60% of the time my laptop wakes from sleep), skhd always misreports iTerm as the culprit. Locking and unlocking the screen fixes the issue 100% of the time for me so it’s no big hardship, just a bit confusing at first.

I found that whatever app I had opened, skhd would report that app as having secure entry turned on. This happened to me after I woke my computer up and logged in again after it had been sleeping overnight. I locked it and unlocked it again, and the problem went away.

Hah, that was it for me as well!

I had this happen to me - turns out it was because 1Password had the editing field open on a password entry in the background. Just closing the entry fixed it.

Seems obvious that that would cause it, but SKHD was reporting Safari or iTerm as the one to enable Secure Input, and I had 1Password hidden and forgotten. So it seems that easy fix is to just quit any app that might have been involved in Secure Input.

This “problem” is because some software running on macOS enables Secure Keyboard Input (which is a security feature to make it harder for keylogging software), and for some reason, some of these applications forget or fail to disable this mode when it is no longer necessary. There is nothing I can to fix this in skhd without losing a lot of the customization power that it currently has.

I keep running into this issue. Just resolved it by locking and unlocking with Touch ID. So definitely not related to Touch ID.

For me it was kitty that was holding the lock:

skhd: secure keyboard entry is enabled by (7422) 'kitty'! abort..

This happens to me a couple of times a week. Is there anything I should capture next time this happens to help root cause the issue?

When it has been loginwindow I have been able to fix by locking and unlocking rather then rebooting.

Is there a solution to this issue? After every reboot/Lock Screen/login this happens with safari, item, loginwindow.

Thanks.

This is almost certainly not related to Touch ID. If it was, you’d see way more complaints on this issue board.

Please just check which process enables Secure Input: If it’s loginwindow, reboot (seems to be a bug that cannot be reproduced reliably), if it’s any other process (as shown above) disable it for that process and restart skhd.

For what it’s worth. In the latest version skhd will try to locate the process that has activated secure keyboard input when it starts, and report the process name and pid. The output is printed to stderr, so if you are running through launchservices you probably need to edit the plist (preferences list) and specify the path for a logfile.

Well, in my case it was actually safari. Turns out in enables secure keyboard entry when you want to get a password from the settings dialogue, and just closing that window did the trick…