auto-selfcontrol does not run on my Macbook

[TarjinderSingh]

I am using a MacBook Air (M1, 2020) on Mac OS 12.0.1 (21A559). I can run auto-selfcontrol activate and it will prompt me for permissions and begin activating. However, it doesn't start based on the given schedule (ie the next day I still have to manually activate it). Is auto-selfcontrol not compatible with the new Mac OS version or the new M1 chips? Thanks!!

[andreasgrill]

I wasn't able to test it on an M1 Mac yet, but I will in the next months.

[TarjinderSingh]

@andreasgrill that would be great! I think #59 also mentioned the same thing, so I guess for the new M1 Macs, the activation does not happen automatically.

[ToonAlfrink]

It has worked for me on my M1 mac just fine, until selfcontrol updated something. Now auto-selfcontrol doesn't trigger like you say

[bwray]

It doesn't work on my MacBook anymore either, but it's NOT an M1. 2016 MBP, macOS 12.0.1

[nadesai]

I also noted the same problems as https://github.com/andreasgrill/auto-selfcontrol/issues/64#issue-1051950896 after I updated to MacOS 12.0.1 on a 2019 MacBook Pro (not an M1).

[andreasgrill]

@nadesai Thanks for pointing that out, I'll be able to look into it in the next few weeks hopefully. Right now, I don't have a macOS 12 system at hand.

[fahrenfort]

I have the same issue: I can activate auto-selfcontrol, but after running it won't re-activate according to schedule. I'm running it on a new MacBook Pro M1 with 12.1 (Monterey). Would be great if this could be resolved, thanks!

[andreasgrill]

I've looked into the issue, but I'm not sure how to solve it yet. I've tested this on an M1 Mac on macOS 12 Monterey, as well as on an Intel Mac on macOS 11 BigSur, both with SelfControl 4.0.2.

If Auto-SelfControl is activated by schedule, it runs the SelfControl command-line methods, but it seems they don't have the necessary rights to install the SelfControl helper tool. That's what I got from the logs:

debug   22:15:05.166965+0100    authd   setting hints for UI authorization
info    22:15:05.167053+0100    authd   Creator of authorization has uid == 0, granting right com.apple.ServiceManagement.blesshelper (engine 2796)
debug   22:15:05.167295+0100    authd   setting hints for UI authorization
error   22:15:05.167336+0100    authd   Fatal: interaction not allowed (session has no ui access) (engine 2796)
[...]
default 22:15:05.167521+0100    selfcontrol-cli ERROR: Failed to authorize installing selfcontrold with status -60007.
debug   22:15:05.167562+0100    selfcontrol-cli Resource lookup at <private>
    Request       : SCError type: strings
    Result        : file:///Applications/SelfControl.app/Contents/Resources/SCError.strings
default 22:15:05.167350+0100    authd   Failed to authorize right 'org.eyebeam.SelfControl.startBlock' by client '/Applications/SelfControl.app/Contents/MacOS/selfcontrol-cli' [40299] for authorization created by '/Applications/SelfControl.app/Contents/MacOS/selfcontrol-cli' [40299] (3,0) (-60007) (engine 2796)
debug   22:15:05.167576+0100    selfcontrol-cli Resource lookup at <private>
    Request       : SCError type: stringsdict
    Result        : None
debug   22:15:05.167859+0100    selfcontrol-cli Bundle: <private>, key: 501, value: , table: SCError, localizationName: (null), result: There was an error authorizing the installation of SelfControl's helper tool.
default 22:15:05.167891+0100    selfcontrol-cli ERROR: Failed to install daemon with error Error Domain=SelfControlErrorDomain Code=501 "There was an error authorizing the installation of SelfControl's helper tool." UserInfo={SCDescriptionNotFound=false, NSLocalizedDescription=There was an error authorizing the installation of SelfControl's helper tool.}
info    22:15:05.168344+0100    opendirectoryd  PID: 40299, Client: 'selfcontrol-cli', exited with 0 session(s), 0 node(s) and 0 active request(s)

The problem could be that launchd, which is used to schedule Auto-SelfControl, starts the process without access to the UI. This could lead to the failed authorization – that's what I got from the logs.

@cstigler what's your take on this. Do you also think this could be the problem and, if so, is there something that could be done in SelfControl or should we look into an alternative way to run schedules?

[nadesai]

In case it is helpful, here is what I see when I try to launch a new SelfControl session via the CLI. Upon running the following command (I have selfcontrol-cli aliased to $APPLICATIONS/SelfControl.app/Contents/MacOS/selfcontrol-cli) at 2022-01-10T15:00:00-08:

selfcontrol-cli start --blocklist $APPLICATIONS/auto-selfcontrol/blocklist --enddate 2022-01-10T15:01:00-08

I then see the following macOS security dialog:

After authentication, the block successfully begins.

When the block expires, running the same command again at 2022-01-10T15:01:30-08, as follows:

selfcontrol-cli start --blocklist $APPLICATIONS/auto-selfcontrol/blocklist --enddate 2022-01-10T15:02:30-08

gives the same security dialog with the same text again, and authentication is again required for the block to successfully start.

Was this the case for the SelfControl CLI prior to macOS 12.0.x? I seem to recall not needing to install a new helper tool after every run, instead being able to authenticate with my machine password on the command line.

[fahrenfort]

Yes, I've also noticed the selfcontrol helper tool authentication (sometimes). Any news on how to fix this? Would be nice to have auto-scheduling capabilities...

[paschalidi]

+1 on this I found this feature very useful 🙇 thx for all the hard work on this one everyone

[andreasgrill]

@nadesai Thanks for testing that. It appears that SelfControl always needs an elevated helper, even when started as root. I've also tried to run SelfControl's CLI as root, but unfortunately the authentication prompt appears anyway:

sudo /Applications/SelfControl.app/Contents/MacOS/selfcontrol-cli --uid 501 start --blocklist ~/.config/auto-selfcontrol/blocklist --enddate 2022-02-12T19:30:26+0100

[nadesai]

I know it's been previously suggested that SelfControl turn into a daemon that only needs one-time authentication (https://github.com/SelfControlApp/selfcontrol/issues/500#issuecomment-581265892 contains some brainstorming) - not sure if the new security restrictions introduced by macOS 12 make even that approach impossible, though.

[alexandernacho]

Is this still being looked at?

[ghost]

Given the issue of the authentication prompt, I changed the launchd plist from a Global Daemon to a User Agent (see https://www.launchd.info for more information), which at least leads me to be automatically prompted. Until the prompt is gone this works for me

[federico012294]

Hi! Any updates on the ARM Macs compatibility with auto-selfcontrol?!

[AlexanderDickie]

I had problems with python2, setup.py and the foundation module so made this- https://github.com/AlexanderDickie/auto-selfcontrol-rs , which should work on intel/apple silicon. I think its way easier to distribute via a binary instead of interpreted language. Like the comments above says, a launch agent works fine and I've added code to immediately relaunch the helper tool installation popup if you cancel it.

[AlexanderDickie]

I created Hammer Control which is a soft solution to this problem. It doesn't get rid of the authentication issue, but it makes it really annoying if you don't authenticate SC to start. Hopefully it makes you actually start the SC session instead of just canceling when the scheduled session starts. It's far from ideal, but it's better than nothing.

haha im about to add 'Mitigate hiding' to my version aswell. Im thinking about simulating keyboard input to just input the password automatically on the helper popup