If you have ever opened Activity Monitor and spotted a process you did not recognize, or noticed your Mac slowing down after installing new software, you have likely brushed up against the world of launch agents vs launch daemons on Mac. Both are part of macOS's launchd system — the master supervisor that starts, stops, and watches background processes. Understanding the difference helps you figure out what is quietly running in the background, why it is there, and whether it needs to be.
What Is launchd and Why Does It Matter?
Every Mac, whether running macOS Sequoia 15 on Apple Silicon or macOS Tahoe on an older Intel machine, boots into a single process called launchd (process ID 1). It is the first user-space process the kernel starts, and it is responsible for launching everything else — from core system services to the menu-bar helper that ships with your VPN app. Instead of running startup scripts line by line, macOS hands launchd a collection of property-list (.plist) configuration files and lets it decide when and how to start each job.
Those configuration files come in two flavors: Launch Agents and Launch Daemons. The names sound interchangeable but they behave very differently.
Launch Agents vs Launch Daemons: The Core Difference
The single most important distinction is which user account runs the process.
- Launch Agents run in the context of a logged-in user. They can display windows, show notifications, or interact with the user's desktop session. They only run while that user is logged in.
- Launch Daemons run as root (or another system user) in the background, independently of whether anyone is logged in. They have no access to the user's GUI and no user interface at all.
A practical example: Dropbox's file-sync helper is a Launch Agent — it needs to know which user's files to watch. A disk-encryption daemon that enforces FileVault policies runs as a Launch Daemon because it must be active before anyone logs in.
Where Do the Plist Files Live?
macOS uses five standard directories for these configuration files. Knowing the locations is essential for auditing what is running on your machine.
| Directory | Type | Who installs here | Requires admin to edit |
|---|---|---|---|
~/Library/LaunchAgents/ |
Agent | Third-party apps, per-user | No |
/Library/LaunchAgents/ |
Agent | Third-party apps, all users | Yes |
/Library/LaunchDaemons/ |
Daemon | Third-party apps, all users | Yes |
/System/Library/LaunchAgents/ |
Agent | Apple (macOS itself) | Locked by SIP |
/System/Library/LaunchDaemons/ |
Daemon | Apple (macOS itself) | Locked by SIP |
The /System/Library/ paths are protected by System Integrity Protection (SIP) and should never be modified. Focus your audit on the two /Library/ paths and your personal ~/Library/LaunchAgents/ folder.
How to See Which Agents and Daemons Are Running
The command-line tool launchctl is your primary interface. Open Terminal and run:
launchctl list— lists every job launchd is managing in the current user's session, along with its PID (if running) and last exit status.sudo launchctl list— shows the system-level (root) job list, which includes daemons.
Each row shows a PID, an exit status, and a label such as com.apple.Safari.SafeBrowsing.Service or com.dropbox.DropboxMacUpdate.Agent. A dash in the PID column means the job is registered but not currently running.
You can also browse the plist files directly in Finder. Press Command-Shift-G in Finder and paste ~/Library/LaunchAgents or /Library/LaunchDaemons to navigate there. Each .plist file is readable plain XML — open one in TextEdit to see the program path, run interval, and any environment variables.
How to Disable or Remove a Launch Agent or Daemon (Step-by-Step)
Before you remove anything, understand what it does. Look up the Label string from the plist in a search engine. If you confirm it belongs to an app you no longer use, here is the safe procedure:
- Unload the job first so macOS stops tracking it:
launchctl unload ~/Library/LaunchAgents/com.example.app.plist(for a user agent) orsudo launchctl unload /Library/LaunchDaemons/com.example.daemon.plist(for a system daemon). - Move the plist to your Desktop rather than deleting it immediately, so you can restore it if something breaks.
- Restart and confirm the app or service still works as expected.
- Delete the plist from your Desktop once you are confident nothing broke.
- If the original app is still installed, completely uninstall the parent app so it does not recreate the plist on next launch.
Do not delete plists from /System/Library/LaunchAgents/ or /System/Library/LaunchDaemons/ — those are owned by macOS and SIP will block you anyway.
Common Offenders: Apps That Leave Agents Behind
Certain categories of software are notorious for installing persistent agents that outlive the app itself:
- Update checkers — many apps install a separate Launch Agent to poll for updates every few hours even when the app is closed. Look for labels containing words like
Update,Updater, orSparkle. - Cloud sync helpers — Dropbox, Google Drive, OneDrive, and similar tools rely on agents to watch the filesystem. These are generally intentional and needed.
- Developer toolchains — tools like Docker Desktop, Postgres.app, and some Homebrew services install daemons that start at boot. If you have stopped using a tool, its daemon may still be consuming CPU and memory.
- Security and VPN software — often install both an agent (user UI) and a privileged daemon (packet routing). Uninstalling only the app sometimes leaves the daemon.
- Old trial software — some apps leave agents behind even after you delete them from
/Applications. This is one of the most common sources of mystery background processes on a Mac that has been in use for a few years.
If you want a complete picture without opening Terminal, a tool like Crumb can audit all of these locations at once and show what each entry maps to before you decide to remove anything.
Are Launch Agents and Daemons Using Significant Disk Space?
The plist files themselves are tiny — typically a few kilobytes each. The disk impact comes from the programs they point to. A daemon that manages a local database might reference a binary in /Library/Application Support/ sitting next to gigabytes of cached data. When you investigate what is counted as System Data in Mac Storage, support folders tied to persistent daemons often account for a surprising share.
To find what a plist actually runs, open it in TextEdit and look for the ProgramArguments key — the first entry is the full path to the executable.
What About Login Items in System Settings?
macOS Ventura and later (including Sequoia and Tahoe) added a dedicated Login Items & Extensions pane in System Settings. This pane surfaces many Launch Agents in a friendlier UI. However, it does not show everything — some daemons installed in /Library/LaunchDaemons/ will not appear here because they do not belong to a specific user session. For a complete audit you still need to check the file system paths listed in the table above.
If an app appears in Login Items but you cannot find a matching plist, it may be using the newer SMAppService API introduced in macOS Ventura, which stores registrations differently. You can manage those entirely through the System Settings UI.
Quick Safety Rules
- Safe to investigate: anything in
~/Library/LaunchAgents/or/Library/LaunchAgents/from an app you no longer use. - Safe to investigate with care: entries in
/Library/LaunchDaemons/from third-party apps — always unload before removing. - Leave alone: everything in
/System/Library/LaunchAgents/and/System/Library/LaunchDaemons/. - When in doubt: search the label string online before touching anything. A five-second search can prevent hours of troubleshooting.