Open jaime10a opened 10 months ago
maybe you need to disable SIP again after an OS upgrade? Also, the entry in sudoers.d may need to be updated / recreated.
Have you checked those cases?
Also from the readme:
After access has been granted, the application must be restarted.
Secure Keyboard Entry must be disabled for skhd to receive key-events.
I guess you've tried skhd --stop-service
, restarted the computer, etc?
Also having this issue, but not sure how it happened. Haven't updated MacOS, currently running Sonoma 14.2, with skhd v0.3.9.
Running skhd
gives the error skhd: must be run with accessibility access! abort..
, despite the fact that skhd has accessibility access in my system settings.
I tried enabling skhd in the input monitoring section, but no change. I also tried running skhd without a config file (renamed skhdrc
to skhdrc.a
).
Next steps for me:
maybe you need to disable SIP again after an OS upgrade? Also, the entry in sudoers.d may need to be updated / recreated.
skhd specifically aborts when run as root; you shouldn't have to modify a sudoers file (as far as I know).
Fix for me included:
I think the accessibility settings somehow got out of sync with the actual settings, but removing and reinstalling fixed the issue for me.
@bustinbung tried your approach but sadly didn't work for me
I found out that my commands with yabai need to end with a semicolon and causing the error. They worked before without a semicolon but now seems to be a problem. If I add an semicolon everything works again.
e.g.
# change window focus within space
alt - down : yabai -m window --focus south;
alt - up : yabai -m window --focus north;
alt - left : yabai -m window --focus west;
alt - right : yabai -m window --focus east;
try to run it with verbose mode and check for errors
skhd -V
semi colons are used in bash to place separate commands on the same line.
eg
echo 'this' ; echo 'that
# is the same as
echo 'this'
echo 'that'
Semi colans are not required by yabai or skhd and will not be the cause of your problem, unless you were inconsistent with them, and that inconsistency caused the problem.
I would recommend removing them all and continue to trouble shoot. Otherwise you're introducing an external factor that will only compliate things down the track when things go wrong.
@camina-apps You may have success restarting your system after removing it.
For those still struggling, I found that skhd started as a service failed to inherit the homebrew bin path -- and thus had no idea where yabai and other brew-installed binaries were. I fixed this by changing my config to use the full path to the yabai executable, like this:
rcmd + rshift + ralt + rctrl + lcmd - right : /opt/homebrew/bin/yabai -m window --space next; /opt/homebrew/bin/yabai -m space --focus next
rcmd + rshift + ralt + rctrl + lcmd - left : /opt/homebrew/bin/yabai -m window --space prev; /opt/homebrew/bin/yabai -m space --focus prev
For those still struggling, I found that skhd started as a service failed to inherit the homebrew bin path -- [...]
That's it!
This did the trick for me.
When I was trying skhd -V
it worked, but not with skhd --start-service
.
After switching to full path commands it started working.
@camina-apps You may have success restarting your system after removing it.
- Remove skhd from accessibility menu
- Uninstall skhd
- Restart system
- Reinstall skhd
- Enable accessibility
This is what finally worked for me (restart was required for this to work). For me I also had to do the following:
$ skhd
- Keyboard Interrupt (after testing that it works) -
$ skhd --start-service
$ skhd --stop-service
$ skhd --start-service
Running skhd
was enough to trip the accessibility warning and add it to the list.
For some reason I had to start the service to get the system to recognize it as a service to be started, stop it manually, and then start it manually again. Just starting it didn't work and I don't know why.
I always got this error when running skhd -V
from the terminal, despite skhd working if started as a service and being present and enabled on System Settings. What fixed it for me was enabling my shell application (in my particular case, Warp) on System Settings Accessibility settings. Maybe this is a Mac noob mistake, but there be noobs out there, so they may benefit from my struggle.
I don't know if this is the correct way to do this or if this can be damaging to the computer but this is how I solved the constant requests for accessibility access
.
Following this thread I decided to try removing skhd
from the accessibility list and see if that would help (specifically using this command sudo sqlite3 /Library/Application\ Support/com.apple.TCC/Tcc.db 'delete from access where client like "%skhd%"'
) and it did. After that it now works like a charm!
In any case I have no clue what other effects directly messing with such an internal data store has but I decided to go for it.
I don't know if this is the correct way to do this or if this can be damaging to the computer
As an initial reaction I would err on the side of caution to make changes like that.. Unless you're confident that it's a service that can be deleted and the OS will rebuild it fresh on reboot (which a lot of com...
files adhear to from my understanding).
But messing with sql databases can be hairy, let alone databases that work with the OS. Any adverse effects may not be noticed till well down the track, by which time this change will have faded from memory..
~I'm having similar issues on Sonoma 14.4.1
, I've followed the steps here and here but have had no luck. Yabai starts up and works but skhd doesn't send any commands~
Upon further review it looks like I had an invalid character in my config that did not previously cause an issue, but in the new version it breaks skhd
cat /tmp/skhd_tatlas.err.log
#70:14 expected modifier
Cant get it to work after macOS update from Ventura to Sonoma.
I always get:
skhd: must be run with accessibility access! abort..
besides having given Accessibility access and restarted. I tried skipping the check_privileges function by always returning true. Then it runs, but also doesn't seem to register key presses.Both brew and building from source give the same result.