Apps & uninstalling
What Are All Those 'Helper' Tools and Daemons on Your Mac?
Helper tools, daemons, and agents on your Mac — what they are, why they exist, and how to find and remove the ones you no longer need.
Open Activity Monitor and scroll through the process list. You’ll see things like Microsoft Update Assistant, AdobeIPCBroker, BackgroundDownloader, mds_stores, cloudd, plus a parade of *-helper and *-daemon processes. Half the names are gibberish. You probably don’t remember installing most of them.
These are helper tools. Here’s what they actually do, why so many exist, and how to clean up the ones you no longer need.
What a helper tool is
A helper is a separate executable spawned by a parent app to do work in the background. The parent app doesn’t have to stay open for the helper to run — that’s the whole point. Helpers exist to do things that:
- Need to keep running after you quit the main app (sync clients, auto-updaters)
- Need elevated permissions the main app doesn’t have (privileged helpers)
- Need to run on a schedule independently
- Are too heavy to embed in the main app
Examples:
- Microsoft AutoUpdate — checks for Office updates whether or not Office is open
- Adobe Genuine Service — verifies your Adobe license in the background
- Dropbox helper — syncs files when the main app is closed
- Steam helper — keeps friends list and downloads going
- Anti-virus daemons — real-time scanning
Most are legitimate. The problem is they accumulate.
Where helpers live
Helpers can live in a few places, depending on what they do and how they’re installed:
/Applications/<App>/Contents/Library/LoginItems/— bundled with the app~/Library/Application Support/<vendor>/<helper>— user-level helpers/Library/Application Support/<vendor>/<helper>— system-level/Library/PrivilegedHelperTools/— privileged helpers (require admin to install)
Each helper is registered with launchd via a .plist file in:
~/Library/LaunchAgents/— user-level, starts at login/Library/LaunchAgents/— all-users, starts at login/Library/LaunchDaemons/— system-level, starts at boot
The .plist is the trigger. The helper executable is the thing being triggered. Both need to exist for the helper to work; if either is missing, you get a silent failure logged in Console.app.
Why so many?
Modern macOS apps are encouraged by Apple to be sandboxed and short-lived. So apps that need to do background work delegate to helpers. The result is one user-installed app frequently means three to five processes:
- The main app
- A login-time launcher
- A sync or update helper
- A privileged helper for things needing root
- A crash reporter
Multiply by a couple of dozen apps and you have a hundred helpers running at any moment.
How to see what’s running
Two tools.
Activity Monitor: Sort by process name. Anything with “helper”, “daemon”, “agent”, “updater”, or “*d” at the end is probably a helper. The CPU and Memory columns tell you whether it’s doing anything.
launchctl list in Terminal: Lists every loaded launchd job. Output:
PID Status Label
102 0 com.apple.cfprefsd.xpc.daemon
104 0 com.apple.coreservices.uiagent
- 78 com.olduninstalled.helper
Status 0 means the agent ran and exited cleanly (or is still running). Non-zero means it failed. Many failures = orphan helpers pointing at missing executables.
The orphan helper problem
When you uninstall a parent app by dragging it to the trash, macOS doesn’t go hunting for the helpers. So:
- The helper executable might or might not be deleted (depending on where it lived)
- The LaunchAgent
.plistis almost always still there - launchd keeps trying to start the helper at every login
- It fails silently
- Your login is fractionally slower
Multiply across years of installs, you have ten or twenty failing helpers at every login. None of them is doing anything useful. All of them are wasting time.
Finding orphan helpers
The systematic approach:
- List installed apps:
ls /Applicationsplusls ~/Applicationsif you have a user-level apps folder. - List
.plistfiles:ls ~/Library/LaunchAgents/,ls /Library/LaunchAgents/,ls /Library/LaunchDaemons/(these last two need admin to view). - For each
.plist, open in TextEdit. Look atProgramArguments— the first item is the executable path. - Check whether the executable exists.
- Check whether the parent app exists.
If neither the executable nor the parent app exists, it’s an orphan.
This takes time. Faster: launchctl list | grep -v "0\s" shows agents with non-zero status, which is a strong signal of orphans.
Removing orphan helpers safely
Once you’ve identified one:
- Move the
.plistto your desktop (don’t trash yet — easier to revert) - In Terminal:
launchctl unload ~/Library/LaunchAgents/<file>.plist(or appropriate path) - Force-quit the helper if it’s running (Activity Monitor)
- Trash the helper executable too if you can find it
- Test: log out and back in, see if anything broke
- If all good, trash the desktop copy of the
.plist
For system-level paths (/Library/LaunchAgents/, /Library/LaunchDaemons/), use sudo launchctl unload ... and supply your password.
.plist is more useful than the filename for identifying what an agent belongs to. Look for the <key>Label</key> value — usually a reverse-DNS string like com.adobe.AdobeIPCBroker that tells you the vendor.Common helpers worth understanding
A short tour of helpers you’ll commonly see:
com.apple.*— macOS itself. Leave alone.com.microsoft.update.agent— Microsoft AutoUpdate. Removable if you’ve uninstalled Office.com.adobe.AdobeIPCBroker— Adobe inter-process broker. Removable post-Adobe uninstall.com.adobe.acc.installer— Creative Cloud installer helper. Often orphan after CC uninstall.com.dropbox.*— Dropbox sync. Needed if you use Dropbox.com.google.keystone.*— Google’s auto-updater (Chrome, Earth, etc.). Needed for any Google app.com.spotify.client.helper— Spotify. Removable if you’ve uninstalled Spotify.com.docker.*— Docker Desktop. Resource-heavy if you don’t use Docker.com.logmein.*— LogMeIn / GoToMeeting. Often left behind from corporate installs.
If you see any of these but no longer have the parent app, it’s removable.
Privileged helper tools
A subcategory worth special mention. Privileged helpers live in /Library/PrivilegedHelperTools/ and run with elevated permissions. They’re installed via the SMJobBless API, which requires admin authentication.
Common privileged helpers:
com.adobe.acc.installer.v2— Adobe install elevationcom.microsoft.autoupdate.helper— Office AutoUpdate elevation- Various anti-virus and backup helpers
These can only be removed with admin. The corresponding LaunchDaemon .plist will be in /Library/LaunchDaemons/. Both need to be removed (helper executable + plist).
Helpers that don’t have an obvious parent
Sometimes you find a helper running and can’t figure out what installed it. A useful trick:
- Get the helper’s full path from Activity Monitor (right-click → Open in Finder shows where it lives)
- Look at the parent folder — usually has the vendor name
- Or, run
ps -ef | grep <helper>to see what command launched it
If you really can’t identify it, search the helper name on Google. Most are unique enough that the first hit identifies the vendor.
Doing it with Sweep
Sweep’s app uninstaller catches helpers automatically when you remove a parent app — that’s how you avoid creating orphans in the first place. For Macs that already have years of accumulated orphans, Sweep also has a separate scan that cross-references LaunchAgents and helpers against installed apps.
The output is a list of orphan helpers grouped by likely parent (when identifiable), with sizes. You confirm what to remove and Sweep handles the unload + delete.
This is one of the cleanups most people don’t realize they need until they do it. The “Mac feels faster after” effect from removing 10–15 orphan helpers and login items is consistently noticeable.
Helpers vs. login items
Worth distinguishing:
- A login item (System Settings → General → Login Items & Extensions, “Open at Login”) is a visible app that opens at login. You see it.
- A helper is a background process that’s typically not visible. You don’t see it.
The login items list shows a fraction of what auto-runs. Helpers and LaunchAgents fill in the rest. Cleaning up only login items leaves most of the auto-start activity untouched.
Quick reference
Common helper paths:
/Library/PrivilegedHelperTools/— privileged/Library/LaunchAgents/— system-level user agents/Library/LaunchDaemons/— system-level root daemons~/Library/LaunchAgents/— user-level~/Library/Application Support/<vendor>/— vendor’s helper executables
To list active agents: launchctl list
To unload one: launchctl unload <path>.plist (add sudo for system paths)
Most useful audit: scroll launchctl list for non-zero status codes. Those are orphans waiting to be cleaned up.
The Mac performs better when it’s not constantly trying and failing to launch things that no longer exist. The cleanup is small per-helper and big in aggregate.