First, I come from Linux so there are many things which confuse me such as daemons.

I installed VOX.app and it has some kind of agents and cloud-related processes which can be started automatically. There is no option in the VOX UI which can disable them. I tried the following to remove those daemons:

launchctl remove com.coppertino.VOXCloud
launchctl remove com.coppertino.VOXAgent

The above commands are weird already because I didn't need to use sudo. The most weird part is what I did is apparently useless since everytime I launch VOX.app, it can create them again and again. This is just crazy.

If this is the security model of macOS how can I understand things and perhaps control for this?

  • There are numerous questions here. This site works best if you ask one question. Commented Aug 18, 2018 at 12:17
  • 1
    I agree - this should be closed if it has multiple related questions asked. Graham has an amazing first overall answer, so I’ve edited all the specific questions out and made this about Apple’s security model. Please ask a follow on question with a very narrow specific follow on question if you have a specific version of an app on a specific macos version you want help preventing it from establishing a startup. There may be general or specific steps to control that
    – bmike
    Commented Aug 18, 2018 at 14:21

2 Answers 2


The general security model is that normal users can add any startup items to their realm (user library for them) and not for the system, so don’t let people have admin accounts if you don’t trust them to not run software that installer system level startup items.

There is no easy way to stop an admin user from changing the system. You can enforce gatekeeper or signed apps, but most admin users can bypass that setting so at best, you slow down an uneducated admin user for a bit.

Per-user and Computer Wide Jobs

On macOS, launchd can manage background processes per-user and computer wide.

Per-user jobs exist within your user session. They start and stop with your logging in and out of the computer. If the jobs have associated job tickets, you will find them with the folder ~/Library/LaunchAgents and ~/Library/LaunchDaemons

Computer wide jobs start and stop with the computer. These jobs are stored in /Library/LaunchAgents and /Library/LaunchDaemons.

Computer wide jobs managed by Apple are stored in /System/Library/LaunchAgents and /System/Library/LaunchDaemons.

Per-user jobs do not need super user permission. Thus you did not need sudo to stop jobs installed at the user level by vox.app.

Disabling a launchd job

You can unload a launchd job to block it returning:

Usage: launchctl unload <service-path, service-path2, ...>

  • -w Additionally disables the service such that future load operations will result in a service which launchd tracks but cannot be launched or discovered in any way.
  • -S <session> Only unloads the services associated with the specified session.
  • -D <domain> Unloads launchd.plist(5) files from the specified domain. See the discussion regarding this same flag when given to the load subcommand for further details.

The -w causes the unload to be written to disk and to persist across sessions.

For more about stopping, unloading, and overriding jobs see:

  • Thanks a lot for the detail explanation. I understand better now. But I am still not able to disable com.coppertino.VOXAgent and com.coppertino.VOXCloud permanently. The two daemons can be found by launchctl list | grep -i vox command and they are not shown in ~/Library/LaunchAgents/ and I don't have the directory ~/Library/LaunchDaemons. I can use launchctl remove to remove them, but the bad part is vox.app can create two daemons automatically whenever I launch it. So I remove it and vox.app creates them and repeat.. Is that possible to stop vox.app creating the two daemons?
    – sgon00
    Commented Aug 18, 2018 at 14:11
  • Use the service path and -w to unload the job. That will stop the job running the future. Who publishes vox.app and have you asked the developers about this behaviour? Commented Aug 18, 2018 at 14:13
  • I am sorry to ask you again. How can I find its path? -w needs path as the argument, but I have no idea what their paths are. I don't find them in any of the directories: ~/Library/LaunchAgents, /Library/LaunchAgents, /Library/LaunchDaemons, /System/Library/LaunchAgents, /System/Library/LaunchDaemons, . I tried to use launchctl list com.coppertino.VOXAgent which does not tell me the path either. I tried to use launchctl print com.coppertino.VOXAgent which returns an error Unrecognized target specifier. I tried to google, don't find anything useful how to find a daemon's path. sorry
    – sgon00
    Commented Aug 18, 2018 at 14:56
  • Please could you ask a new question for this. A new question will attract more specific answers and a wider audience. Commented Aug 18, 2018 at 19:08

The general problem is handled in Graham Miln's answer. This answer is only a slight addition exercised upon the example application given:

Short version: macOS has a few special directories for this kind of behaviour. Those are the global and user /Library paths already mentioned in Graham's answer. But a less visible and hence less obvious path is within each Application bundle.

Some apps are too clever. Vox is a prime example of this. These agents are not well explained but often complained about and thus a potentially unwanted programme, application or software (PUPAS)

This application triggers a chain of events already when it is being copied to /Applications and again when first launched.

Inside the package bundle are LoginItems:

  ../VOX Agent.app

Both are the copied/registered by the system's own DesktopServicesHelper as an "application helper login item". These kind of "helpers" are often found in other apps as well and are usually just bloat adding nuisances. They might be blocked preemptively from registering in the first place by handy little apps, like BlockBlock.

As these are still contained within the app bundle you would have to search or supply the path to within the app bundle!

A search for automatically launched programmes/helpers has to include /Applications and ~/Applications!

Another annoyance is then found within the app bundle:

 /Volumes/VOX/VOX.app/Contents/XPCServices/VOX\ Toolbox.xpc

One way to disable these per-user processes from bothering you is outlined in Graham's answer, using launchctl.
You just need to search within /Applications as well.
Another method would be to go into the bundle and just delete these items. – Most of the time those apps start fine without them, just missing the respective functionality. Vox was once a nice little 'no-frills' music player. It does work for that without those annoyances present on disk.
Sometimes better designed applications offer you an option to prevent those shenanigans in their preference dialogue.

Personal favorite: In the case of the application in the example given, it would be best to delete the whole application.

To directly answer the quesion headline of

Why can an app create daemons on the fly without sudo permission and how to stop it?

Because a user launches the app with his privileges and daemons contained within that application bundle are then sometimes quite annoyingly designed to then register themselves quite intransparently as "autostart" within that user's context and with that user's rights. To unload or deregister no sudo/administrative rights or permissions are required. If the offender sits under /Applications then removal might depend on higher permissions.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .