Homebrew-cask: uninstalling casks with 'login items' can fail on macOS 10.14 'Mojave'

Created on 3 Aug 2018  Â·  15Comments  Â·  Source: Homebrew/homebrew-cask

General troubleshooting steps

  • [x] I have retried my command with --force and the issue is still present.
  • [ ] I have checked the instructions for reporting bugs.

    • [ ] None of the templates was appropriate for my issue, or I’m not sure.

  • [x] I ran brew update-reset && brew update and retried my command.
  • [x] I ran brew doctor, fixed as many issues as possible and retried my command.
  • [ ] I understand that if I ignore these instructions, my issue may be closed without review.

Description of issue

uninstalling casks with 'login items' fails on macOS 10.14 'Mojave'

Command that failed

brew cask uninstall --force 1clipboard

Output of command with --force --verbose --debug

$ brew cask uninstall --force --verbose --debug 1clipboard
==> Uninstalling Cask 1clipboard
==> Uninstalling Cask 1clipboard
==> Un-installing artifacts
==> 3 artifact/s defined
#<SortedSet:0x00007fc694226f98>
==> Un-installing artifact of class Hbc::Artifact::Uninstall
==> Running uninstall process for 1clipboard; your password may be necessary
==> Quitting application ID com.ngwin.1clipboard
==> /bin/launchctl list
==> Quitting application ID com.ngwin.1clipboardhelper
==> /bin/launchctl list
==> Removing login item 1Clipboard
==> /usr/bin/osascript -e tell\ application\ \"System\ Events\"\ to\ delete\ every\ login\ item\ whose\ name\ is\ \"1Clipboard\"
36:86: 
execution error: Not authorised to send Apple events to System Events. (-1743)
Error: Failure while executing; `/usr/bin/osascript -e tell\ application\ \"System\ Events\"\ to\ delete\ every\ login\ item\ whose\ name\ is\ \"1Clipboard\"` exited with 1. Here's the output:
36:86: execution error: Not authorised to send Apple events to System Events. (-1743)


Follow the instructions here:
  https://github.com/Homebrew/homebrew-cask#reporting-bugs
/usr/local/Homebrew/Library/Homebrew/system_command.rb:97:in `assert_success'
/usr/local/Homebrew/Library/Homebrew/system_command.rb:46:in `run!'
/usr/local/Homebrew/Library/Homebrew/system_command.rb:21:in `run'
/usr/local/Homebrew/Library/Homebrew/system_command.rb:25:in `run!'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/abstract_uninstall.rb:160:in `block in uninstall_login_item'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/abstract_uninstall.rb:158:in `each'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/abstract_uninstall.rb:158:in `uninstall_login_item'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/abstract_uninstall.rb:58:in `block in dispatch_uninstall_directives'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/abstract_uninstall.rb:55:in `each'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/abstract_uninstall.rb:55:in `dispatch_uninstall_directives'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/uninstall.rb:7:in `uninstall_phase'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/installer.rb:441:in `block in uninstall_artifacts'
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/set.rb:674:in `each'
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/set.rb:674:in `each'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/installer.rb:438:in `uninstall_artifacts'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/installer.rb:391:in `uninstall'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/uninstall.rb:22:in `block in run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/uninstall.rb:12:in `each'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/uninstall.rb:12:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/abstract_command.rb:33:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:93:in `run_command'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:157:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:122:in `run'
/usr/local/Homebrew/Library/Homebrew/cmd/cask.rb:7:in `cask'
/usr/local/Homebrew/Library/Homebrew/brew.rb:87:in `<main>'
Error: Kernel.exit
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:168:in `exit'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:168:in `rescue in run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:145:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:122:in `run'
/usr/local/Homebrew/Library/Homebrew/cmd/cask.rb:7:in `cask'
/usr/local/Homebrew/Library/Homebrew/brew.rb:87:in `<main>'

Output of brew cask doctor

$ brew cask doctor
==> Homebrew-Cask Version
Homebrew-Cask 1.7.1
Homebrew/homebrew-cask (git revision f78c; last commit 2018-08-03)
==> macOS
10.14
==> SIP
Disabled
==> Java
N/A
==> Homebrew-Cask Install Location
<NONE>
==> Homebrew-Cask Staging Location
/usr/local/Caskroom
==> Homebrew-Cask Cached Downloads
~/Library/Caches/Homebrew/Cask (8 files, 418MB)
==> Homebrew-Cask Taps:
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask (4014 casks)
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask-versions (191 casks)
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask-eid (11 casks)
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask-fonts (1164 casks)
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask-drivers (152 casks)
==> Contents of $LOAD_PATH
/Library/Ruby/Gems/2.3.0/gems/did_you_mean-1.0.0/lib
/Library/Ruby/Site/2.3.0
/Library/Ruby/Site/2.3.0/x86_64-darwin18
/Library/Ruby/Site/2.3.0/universal-darwin18
/Library/Ruby/Site
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/vendor_ruby/2.3.0
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/vendor_ruby/2.3.0/x86_64-darwin18
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/vendor_ruby/2.3.0/universal-darwin18
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/vendor_ruby
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/x86_64-darwin18
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/universal-darwin18
/usr/local/Homebrew/Library/Homebrew/cask/lib
/usr/local/Homebrew/Library/Homebrew
==> Environment Variables
LC_ALL="en_US.UTF-8"
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/Homebrew/Library/Homebrew/shims/scm"
SHELL="/bin/bash"

Output of brew tap

$ brew tap
homebrew/cask
homebrew/cask-drivers
homebrew/cask-eid
homebrew/cask-fonts
homebrew/cask-versions
homebrew/core
vitorgalvao/tiny-scripts

Most helpful comment

i just updated to '18A347e'. now i got a dialog asking if "terminal" can control system events. if i click yes it works. if i click no, i get the error as mentioned.

the problem is, if you click no by accident, the dialog won't appear again, and it won't work unless you manually go to System Preferences => Privacy => Automation => Terminal and check "System Events"

All 15 comments

What version of Mojave?

this is 18A336e but i'll update to the latest one later today and re-test.

i just updated to '18A347e'. now i got a dialog asking if "terminal" can control system events. if i click yes it works. if i click no, i get the error as mentioned.

the problem is, if you click no by accident, the dialog won't appear again, and it won't work unless you manually go to System Preferences => Privacy => Automation => Terminal and check "System Events"

@core-code There’s nothing we can do about that, nor would we want to. That’s part of macOS’ security model, which is even tighter in Mojave.

Even Chrome is starting to do that. In the latest release, you can’t even control Chrome via JavaScript unless you select an option.

well, ideally 'brew' should detect that its action has been blocked by Mojave security and kindly ask the user to go to
System Preferences => Privacy => Automation => Terminal and check "System Events"
instead of failing super cryptically

That’s part of macOS’ security model, which is even tighter in Mojave.

We use AppleScript for login_item, quit and trash. Are they all going to be affected by this?

well, ideally 'brew' should detect that its action has been blocked by Mojave (…)

Agreed.

We use AppleScript for login_item, quit and trash. Are they all going to be affected by this?

I don’t have a machine to test, but I’m pretty sure the answer is “yes, but it doesn’t matter”. Permission is given on an per-app basis, so if you give permission for one of these actions, all will be allowed (the reverse also being true).

It looks like the system works like what we already had (since at least Sierra) in terms of permissions, but it’s tighter in what it allows by default.

I have this in my dotfiles to detect if I have enabled access for Terminal, does this still work on Mojave, @core-code?

# Accessibility Access 
if test -z "$(/usr/bin/sqlite3 '/Library/Application Support/com.apple.TCC/TCC.db' \
              "SELECT * FROM access WHERE client = 'com.apple.Terminal' AND allowed = 1")"; then
  echo "\033[0;31mPlease enable Accessibility Access for 'Terminal.app' in System Preferences.\033[0m" 1>&2
  /usr/bin/open 'x-apple.systempreferences:com.apple.preference.security?Privacy_Accessibility'
  /usr/bin/open -R /Applications/Utilities/Terminal.app
  exit 1
fi

@reitermarkus: i think so. when i run it, it prints "Please enable Accessibility Access for 'Terminal.app' in System Preferences." and 1.) shows the terminal in a finder window and 2.) opens System Preferences => Privacy => Accessibility however, we are talking here about the new 'Automation' section in "System Preferences => Privacy" which seems to be something different.

the SQLLite check certainly seems to work, i just ran this:

/usr/bin/sqlite3 '/Library/Application Support/com.apple.TCC/TCC.db' "SELECT * FROM access"

=>

kTCCServiceAccessibility|at.obdev.LaunchBar|0|0|1||||UNUSED||
kTCCServiceAccessibility|org.corecode.KeyPresser|0|0|1||||UNUSED||
kTCCServiceAccessibility|com.getdropbox.dropbox|0|0|1||||UNUSED||
kTCCServicePostEvent|com.plexapp.plexhometheater|0|0|1||||UNUSED||
kTCCServicePostEvent|tv.openpht.openpht|0|0|1||||UNUSED||
kTCCServiceAccessibility|com.setapp.DesktopClient.SetappAgent|0|0|1||||UNUSED||
kTCCServicePostEvent|com.amazon.music|0|0|1||||UNUSED||

however, we are talking here about the new 'Automation' section

But does adding Terminal.app in that section affect /Library/Application Support/com.apple.TCC/TCC.db?

i've inspected the 'TCC.db' database and the things added to the 'Automation' section don't seem to be in there. they must be stored in some other way

but they seem to be in the same file in the user library, i.e. its contained in

~/Library/Application Support/com.apple.TCC/TCC.db

screenshot 2018-08-04 at 20 14 09

@core-code how did you uninstall it? because this is still an issue in version 1.9.2.

@webknows you can edit the cached copy of the caskfile to get any offending cask to uninstall

edit
/usr/local/Caskroom/CASKNAME/.metadata/CASKVERSION/WEIRDIDENTIFIER/Casks/CASKNAME.rb
and uncomment the offending secttion, e.g. the loginitem thing in this case

Was this page helpful?
0 / 5 - 0 ratings