Sweepfor Mac

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.

8 min read

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.

There’s a faster waySweep does the same hunt in seconds, with a preview before anything is removed. Try Sweep free →

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 .plist is 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:

  1. List installed apps: ls /Applications plus ls ~/Applications if you have a user-level apps folder.
  2. List .plist files: ls ~/Library/LaunchAgents/, ls /Library/LaunchAgents/, ls /Library/LaunchDaemons/ (these last two need admin to view).
  3. For each .plist, open in TextEdit. Look at ProgramArguments — the first item is the executable path.
  4. Check whether the executable exists.
  5. 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:

  1. Move the .plist to your desktop (don’t trash yet — easier to revert)
  2. In Terminal: launchctl unload ~/Library/LaunchAgents/<file>.plist (or appropriate path)
  3. Force-quit the helper if it’s running (Activity Monitor)
  4. Trash the helper executable too if you can find it
  5. Test: log out and back in, see if anything broke
  6. 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.

Tip: The label inside a .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 elevation
  • com.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.

Skip the manual huntSweep finds every leftover preference, cache, and support file in seconds — and only removes what you OK. Download Sweep free →

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.

← Back to all guides