By MacPaw · Verified on macOS Tahoe 26.0 (Apple Silicon, M3 Pro) and macOS Sonoma 14.6 (Intel Core i7) · Updated July 2026

macOS Launch Agents and Daemons: A Complete Audit Guide

Every Mac ships with hundreds of launch agents and daemons. Most of them belong to Apple and run silently at the system level behind SIP. The ones you need to care about are the third-party additions: the update checkers, the crash reporters, the helper processes, and the occasional piece of adware masquerading as a legitimate background service. After three years of installing and uninstalling software, a Mac can accumulate dozens of these, some still running long after their parent apps were deleted.

This guide covers what launch agents and daemons actually are, where every plist file lives on a modern Mac, how to read them, how to identify which ones to remove, and how to do it without breaking anything. All commands are verified on macOS Tahoe 26.0 and Sonoma 14.6; version-specific differences are called out inline.

What launch agents and daemons are

launchd is the root process on every Mac — PID 1. Everything that runs on macOS is ultimately a child of launchd, including the Finder, the Dock, and every background service. launchd reads configuration files called property lists (plists) at boot and at login to determine what to start, when to start it, and how to restart it if it crashes.

There are two categories of launchd-managed items:

A launch agent is scoped to a user session. It starts when you log in, has access to your display and user environment, and stops when you log out. A launch daemon starts at boot as root, has no access to the GUI, and keeps running regardless of who is or isn't logged in. The security implication: a malicious launch daemon runs as root; a malicious launch agent runs as you. Both are bad. Root is worse.

Where every plist lives: the complete location map

There are six canonical plist directories on a modern Mac. Here they are in order from most-relevant-to-audit to least:

The two /System/Library paths contain around 400–500 Apple-owned plists on a typical Tahoe installation. They are protected by System Integrity Protection (SIP) — you cannot modify or delete them even as root without first disabling SIP in Recovery Mode. There is no reason to audit these unless you're debugging a specific macOS subsystem; for startup cleanup purposes, they are off-limits.

Your target is the three editable directories: ~/Library/LaunchAgents, /Library/LaunchAgents, and /Library/LaunchDaemons.

Step 1: Count what you have

# Count plists in each auditable directory
ls ~/Library/LaunchAgents | wc -l
ls /Library/LaunchAgents | wc -l
ls /Library/LaunchDaemons | wc -l

Sample output on a 3-year-old MacBook Pro M3 Pro running Tahoe 26.0 that had never been audited:

      34
      19
      22

75 third-party agents and daemons, on a machine that was believed to have "not much installed." This is typical. Every app that runs in the background — updaters, sync clients, crash reporters, antivirus helpers, VPN components — adds at least one plist. They accumulate silently and none of them ask permission to stay after the parent app is removed.

Step 2: See what's actually running right now

launchctl list | head -30

The output has three columns: PID, last exit status, and service label. Here's what each column tells you:

Filter to just the non-Apple entries:

launchctl list | grep -v "com.apple" | grep -v "^-.*apple"

For daemons (requires admin):

sudo launchctl list | grep -v "com.apple"

Anything with a non-zero exit status and no currently running PID is a broken agent — either its binary was deleted (app uninstalled improperly) or the binary path in the plist no longer exists. These are safe to remove and doing so slightly speeds up login by reducing launchd's startup work.

Step 3: Read a plist to identify what it does

Plist files can be in binary or XML format. To read either format in Terminal:

plutil -p ~/Library/LaunchAgents/com.example.someagent.plist

Or convert binary to readable XML:

plutil -convert xml1 -o - ~/Library/LaunchAgents/com.example.someagent.plist

The four keys to look for in any plist:

A legitimate update-checker plist looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.someapp.updatechecker</string>
  <key>ProgramArguments</key>
  <array>
    <string>/Applications/SomeApp.app/Contents/MacOS/SomeAppUpdater</string>
    <string>--check</string>
  </array>
  <key>RunAtLoad</key>
  <false/>
  <key>StartInterval</key>
  <integer>86400</integer>
</dict>
</plist>

Points that build confidence: the program path is inside a named app bundle in /Applications, the label matches the filename, the start interval is 86400 seconds (once a day), and RunAtLoad is false so it doesn't add to login time. A suspicious plist for contrast would have a Program path pointing to a file in ~/Library/Application Scripts/com.somerandombundleid/, RunAtLoad set to true, and a StartInterval of 60 seconds.

Step 4: Check whether the binary actually exists

One of the fastest ways to clean up is to remove plists whose binaries no longer exist. Run this against each directory:

for f in ~/Library/LaunchAgents/*.plist; do
  binary=$(plutil -extract ProgramArguments.0 raw "$f" 2>/dev/null \
           || plutil -extract Program raw "$f" 2>/dev/null)
  if [ -n "$binary" ] && [ ! -e "$binary" ]; then
    echo "MISSING BINARY: $f -> $binary"
  fi
done

Sample output:

MISSING BINARY: /Users/you/Library/LaunchAgents/com.adobe.ARMDCHelper.plist -> /Library/Application Support/Adobe/Adobe Desktop Common/ADS/Adobe Desktop Service.app/Contents/MacOS/Adobe Desktop Service
MISSING BINARY: /Users/you/Library/LaunchAgents/com.microsoft.update.agent.plist -> /Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/Microsoft AutoUpdate
MISSING BINARY: /Users/you/Library/LaunchAgents/com.dropbox.DropboxMacUpdate.agent.plist -> /Applications/Dropbox.app/Contents/MacOS/DropboxMacUpdate

Every plist with a missing binary is an orphan — the parent app was deleted without a proper uninstaller. These are safe to remove immediately.

Step 5: Disable or remove agents safely

Unload an agent without deleting it (reversible)

# Temporarily disable — re-enables on next login
launchctl unload ~/Library/LaunchAgents/com.someapp.agent.plist

# Permanently disable (survives reboot) — Sonoma and earlier
launchctl unload -w ~/Library/LaunchAgents/com.someapp.agent.plist

Unload using the modern API (Tahoe / Ventura preferred)

On macOS Ventura and later, launchctl unload is deprecated in favor of the domain-target syntax:

# For user agents (replace 501 with your UID from `id -u`)
launchctl bootout gui/501/com.someapp.agent

# For system daemons
sudo launchctl bootout system/com.someapp.daemon

Permanently remove an agent

# Unload first, then delete
launchctl bootout gui/$(id -u)/com.someapp.agent
rm ~/Library/LaunchAgents/com.someapp.agent.plist

For system-level items in /Library/LaunchDaemons:

sudo launchctl bootout system/com.someapp.daemon
sudo rm /Library/LaunchDaemons/com.someapp.daemon.plist

The Login Items & Extensions panel in macOS Tahoe

macOS Tahoe 26.0 expanded the Login Items panel in System Settings > General > Login Items & Extensions. It now groups background items by the app that registered them, rather than showing a flat list. If Adobe Creative Cloud registered three agents and a daemon, you'll see a single "Adobe Creative Cloud" row you can expand to see all four. Toggling the row off disables all of them in one action.

What changed from Sonoma to Tahoe in this panel:

One limitation persists on both releases: the panel shows items registered through the official SMAppService API and legacy plist installs notified to the system, but it does not show every plist file present in the LaunchAgents directories. An orphaned plist from a deleted app will not appear in System Settings — it only appears in Terminal and in the launchctl list output. This is why Terminal audit steps remain necessary even on Tahoe.

Identifying malicious agents

Launch agents are one of the most common persistence mechanisms for Mac adware and spyware. The Adload family and Atomic Stealer (AMOS) both use them. Red flags to look for in your audit:

• Program path outside /Applications or /Library — legitimate helpers live inside app bundles or in /Library/Application Support. An agent pointing to /private/tmp, a hidden folder in your home directory, or ~/Library/Application Scripts warrants immediate investigation.
• Label that doesn't match the filename — the plist filename and the Label key inside it should match. A mismatch is unusual for legitimate software.
• Misspelled bundle IDs — common adware tactic. com.gogle.update instead of com.google.update, for instance.
• Very short StartInterval (under 300 seconds) — a legitimate updater doesn't need to run every 60 seconds.
• No corresponding app in /Applications — if the plist label suggests it belongs to an app you don't have installed, it's either an orphan or something that was installed without your knowledge.

XProtect and Gatekeeper catch known-bad binaries. They do not catch a plist pointing to a binary that was clean when it was installed and later downloaded a malicious payload. Manual review remains the only way to catch that class of threat.

Agents that keep coming back

If you delete a launch agent plist and it reappears after the next login, the parent application is reinstalling it. This happens because the app itself — still installed and running — checks on startup whether its agent plist is present, and recreates it if not. Deleting the plist is the wrong fix; it's a loop. The correct fix is to fully uninstall the parent app, including its support files.

Check which app owns the agent by looking at the Program path in the plist, then uninstall that app completely. Dragging a .app to Trash leaves behind the support files and the mechanism that recreates the agent. For this specific scenario — stubborn launch agents from half-removed apps — an automated Mac maintenance app that handles full app uninstallation (application bundle plus all support files, caches, and launch plists) is more reliable than a manual approach across four separate directories.

Common agents you'll find and whether to keep them

Homebrew services: use brew, not launchctl

If you use Homebrew, some of your launch agents will be Homebrew-managed services — databases, web servers, background tools installed via brew install with brew services start. For these, use Homebrew's own service management rather than directly manipulating plists:

# See all Homebrew services and their status
brew services list

# Stop a running service (and disable at login)
brew services stop postgresql@14

# Remove the plist entirely
brew services rm postgresql@14

Deleting a Homebrew service plist manually can put Homebrew's service tracking state out of sync with what's actually on disk, causing confusing behavior on the next brew services run.

What this guide won't fix

Auditing launch agents and daemons will not reduce your visible startup time if the bottleneck is something else — a slow spinning-disk drive, a large Spotlight index rebuild, or a heavy Login Item (like a full app set to open at login via System Settings rather than a launchd plist). It also will not help with agents protected by SIP, and it will not identify or remove kernel extensions (a largely deprecated mechanism replaced by System Extensions, which have their own management path in System Settings). If you audit all three launchd directories, remove orphaned plists, and your Mac still starts slowly, the next diagnostic step is Activity Monitor's CPU tab in the first two minutes after login — not more launchd cleanup.

Frequently asked questions

Written and verified by MacPaw on macOS Tahoe 26.0 and macOS Sonoma 14.6. Terminal commands and System Settings paths reviewed every 90 days as macOS updates ship.