skhd
skhd copied to clipboard
koekeishiya
Doesn't seem to work on Big Sur 11.3.1
The service is started but is not responding to keypresses.
Trying to start it manually with skhd -V results in:
skhd: successfully created pid-file..
skhd: secure keyboard entry is enabled by (1662) 'iterm2'! abort..
Even though secure keyboard entry is disabled in the menu. It's the same for the built-in terminal app.
Same issue, however, skhd -V, for me returns could not lock pid-file! abort .., going to disable system integrity and recheck
After a restart of MacOS everything seems to be back to normal again. Might have been a one-time occurrence.
I tried restarting and skhd worked again for about 5 or 10 minutes before it stopped.
Seems like a lot of stuff has this issue. I just tried the sleep suggestion and that has fixed it for a few minutes now.
https://apple.stackexchange.com/questions/331557/is-there-a-way-to-fix-or-disable-secure-input
Even that workaround (standby+ wakeup) does not work on my macbook pro. I updated to BigSur 11.3.1 yesterday and immediately had problems. skhd did not respond, while yabai commands in the terminal still worked. Strangely (yesterday) skhd showed no errors when started with skhd -V but simply did not work ("-V" made it show som eof the loaded Shortcuts). What made it work again was (strangely enough) to replace ~/.skhdrc with a blank one and redoing the same shortcuts as before. Maybe I had introduced a typo somewhere or I did a standby ans wakeup cycle in between, idk.
Today skhd first worked normally but suddenly, after a longer standby (30 min+) it stopped working and shows
skhd -V
skhd: successfully created pid-file..
skhd: secure keyboard entry is enabled by (59706) 'iterm2'! abort..
EDIT: Needless to say, "secure keyboard entry" is disabled in iterm2. And even in application which have a terminal but don't even have the "secure keybaord entry" option (AFAIK) like VScode:
skhd -V
skhd: successfully created pid-file..
skhd: secure keyboard entry is enabled by (24872) 'code'! abort..
If I can provide any (debug-) logs, please let me know.
While standby + wakeup did not work, logout + login did (for now). I will report back if it fixes it (semi-permanently).
And now it stopped working again. Last steps were to switch to an app (Signal Messenger Desktop app) and then trying to switch to desktop no. 1 (current shortcut "cmd + 1"). That shortcut is used in the Signal app to switch to the first conversation.
Now I get the "secure keyboard entry is enabled" message again.
Sometimes the secure keyboard gets enabled globally and I lock the computer and log in back and the secure keyboard mode is disabled. This might be a helpful trick. BetterTouchTool shows warnings when the secure keyboard mode is enabled. I thought someone may find these tricks useful.
I can confirm that Locking and Unlocking works as a work-around but BTT did not show any warning. Could you check if you have configured BTT to switch back to the old keybaord implementation if "Secure Input" gets enabled (In the BTT Keyboard settings)? This looks like a setting that could cause this warning.
I'm seeing this problem and I don't have BTT installed, so I don't think it's that.
No, but the warning by BTT could be a good indicator about when it happens.
I am on Big Sur 11.4. I tried everything (uninstall, sleep, restart, logout and login etc) but always keep getting "secure keyboard entry is enabled by iTerm2! abort..". Tried with other terminal emulators such as kitty and Terminal as well. Same result even though "Secure Keyboard Entry" is disabled.
Finally, I tried closing everything on the machine and ssh'd into it from another macbook pro. Guess what! Now I get "secure keyboard entry is enabled by Finder! abort.."!!
What makes this more confusing is that skhd works fine the other macbook pro which is running Big Sur 11.4 too.
Hope the above data point is helpful in debugging. At this point I gave up. I have different software on the machine causing problems than on the one that works. Maybe one of software is causing this issue. Sometime over the weekend, I will try wiping the rogue machine clean and see if skhd works with a fresh install
I am having similar issues, namely could not lock pid-file. This may be related to #82? I tried the workaround suggested there and got skhd working by stopping the homebrew services (brew services stop skhd), removing the pid singleton (rm /tmp/skhd_${USER}.pid), and starting skhd in a non-daemonic form with skhd or skhd -V for more information.
I also tried launching the daemon by loading the skhd plist using launchctl, but that did not work either.
For reproducibility, im using skhd v0.3.5 on MacOS X 11.4.
Ive played with starting a daemonic like process without using launchctl and I just got this to work:
nohup skhd &
This will not persist through restarts or logouts, but it does the trick for now. Basically this is starting skhd in the background and suppressing the SIGHUP signal. Meaning that when the parent process is closed, Terminal in this case, skhd is not killed.
Just as an update, the could not lock pid-file is a non-issue for me. This is shown when the daemon process has been started by brew services or equivalently, launchctl load /path/to/skhd.plist. So, you are trying to start a new instance of skhd when it is already running, and thus the first process has the lock on the pid file.
hi @x-ji , i faced the same issue and resolved it by following the instructions on this blog post.
you'll need to disable the Secure Keyboard Entry option on iTerm before restarting your machine
It seems you have to add skhd to Input Monitor which is located at System Preferences -> Security & Privacy -> Privacy Tab -> Input Monitoring. You can just drag the file into the list to add it. Maybe you can check out whether this is the problem.
After adding to this list, my skhd finally works again on Mac Big Sur.
Adding skhd to Privacy > Input Monitoring did not work for me on 11.5.2. I tried many restarts and logging out between other troubleshooting avenues like manually writing the PID to the PIDFILE.
For me it took a couple of trials to understand what was happening.
First, I tried to run skhd using /usr/local/opt/skhd/bin/skhd rather than the brew services start or restart.
The command above gave the following error:
skhd: secure keyboard entry is enabled by (2638) 'terminal'! abort..
Now, despite having secure keyboard turned off on my terminal, it seemed that some app(s) is controlling that! so I ran 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.
For me, the culprit turned out to be Keybase, uninstalling that gave me my skhd back!
per https://github.com/koekeishiya/skhd/issues/48#issuecomment-590531621
ioreg -l -w 0 \
| perl -nle 'print $1 if /"kCGSSessionSecureInputPID"=(\d+)/' \
| uniq \
| xargs -I{} ps -p {} -o comm=
shows that /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow is my problem.
Not sure how to fix other than a restart
For those experiencing this issue, I found that Chrome (or in this case Chrome via Vivaldi Browser) on my mac triggered this when I was simply on a login page for a website (in some cases)
Yet, when I tried things to troubleshoot like: https://github.com/koekeishiya/skhd/issues/172#issuecomment-1028389241,
the loginwindow process was flagged as the culprit. But, killing this process or locking/unlocking my mac did not resolve this.
Every time I attempted to run skhd -V in my terminal to troubleshoot the program starting, I would get errors like mentioned here:
https://github.com/koekeishiya/skhd/issues/172#issuecomment-916281758
i.e. skhd: secure keyboard entry is enabled by (2638) 'terminal'! abort..
regardless of the terminal program I used (I have both hyper and alacritty).
Turned out the problem was just because I was on a login page for a web app in Chrome. Closing the tab with the login screen resolved the issue immediately and skhd started working right away.
Just something to consider....may be the cause of your problem as well.
For those experiencing this issue, I found that Chrome (or in this case Chrome via Vivaldi Browser) on my mac triggered this when I was simply on a login page for a website (in some cases)
Yet, when I tried things to troubleshoot like: #172 (comment), the
loginwindowprocess was flagged as the culprit. But, killing this process or locking/unlocking my mac did not resolve this.Every time I attempted to run
skhd -Vin my terminal to troubleshoot the program starting, I would get errors like mentioned here: #172 (comment) i.e.skhd: secure keyboard entry is enabled by (2638) 'terminal'! abort..regardless of the terminal program I used (I have both hyper and alacritty).Turned out the problem was just because I was on a login page for a web app in Chrome. Closing the tab with the login screen resolved the issue immediately and skhd started working right away.
Just something to consider....may be the cause of your problem as well.
Thanks!
I had the same problem with it telling me it was enabled by what ever terminal I was testing with. For me, it was not a Chrome tab that was the problem. It was the GitHub desktop app asking to unlock my key. After completing this prompt, skhd started to work instantly without reboot.
I should probably report that skhd has been working for me probably since shortly after my post above. Not sure what changed though.
Sure. I haven't used skhd in a while though from what I remember it seemed to work the last time I tried.
To leave something useful for the next desperate: it happened to me with a Chrome extension configured to read "When you click the extension." I solved the issue by changing to be able to read on all sites.
