In this article
The distinction helps explain why one helper belongs to your account while another may continue beyond your logout. It does not tell you whether either helper is useful, unwanted, or safe to remove. To answer those questions, connect the configuration to an executable and an app first.
Start with the app, then inspect its helper
Look for the app or developer in Login Items & Extensions, including the background activity section. This is the simpler starting point when your actual question is “Why does this app do something after I close its window?”
If the displayed name is unfamiliar, follow the evidence in our guide to identifying an unknown background item. Do not delete files merely because their names do not match the app's marketing name.
Apple's current helper-management documentation explains that modern apps can register login items, agents and daemons through Service Management. In macOS 13 and later, helper property lists can live inside an app bundle. A search of the traditional Library folders therefore does not cover every modern registration arrangement.
Also distinguish Open at Login from background activity. Opening the main app and authorizing a helper are different actions, even when both are associated with the same product.
Compare context before comparing names
The basic comparison is about where the service operates:
| Question | LaunchAgent | LaunchDaemon |
|---|---|---|
| What is its context? | A user's session | The system |
| Does it depend on one user's login session? | A session agent belongs to that session | It can operate independently of that session |
| Is every configured job always running? | No | No |
| Does its type establish trust? | No | No |
Apple's launchd guide describes loading job definitions and starting jobs when needed. It also describes ending session agents at logout. This is archived developer documentation; use it for the underlying distinction, alongside the current Service Management documentation for modern app packaging.
Think of a helper that needs a user's desktop environment differently from a service that serves the machine. Both can be legitimate. Neither category is, by itself, a malware verdict.
What the Library folders mean
In Finder, choose Go → Go to Folder and enter the location you want to inspect. Reading a folder does not require moving, editing, or removing its contents.
Apple's Terminal guide to scripts and launchd lists the traditional locations:
| Location | Traditional purpose |
|---|---|
~/Library/LaunchAgents | Agents supplied for the current user |
/Library/LaunchAgents | Third-party agents available on a per-user basis |
/Library/LaunchDaemons | Third-party system services |
/System/Library/LaunchAgents | Apple agents on a per-user basis |
/System/Library/LaunchDaemons | Apple system services |
The leading ~ means your home directory. Without it, /Library is a different location. In particular, an agent in /Library/LaunchAgents does not become a system daemon merely because the folder is shared across accounts.
Keep Apple's system folders as reference material. This comparison is not a cleanup list, and the number of entries is not a measure of how many unnecessary processes are consuming resources.
A daemon does not automatically mean root
“System context” and “execution user” are separate facts. A system service can be configured to run under a dedicated account rather than root. On the tested Mac, the installed launchd.plist manual documents the optional UserName key for services in the privileged system domain.
We checked Apple's own files on October 11, 2026, on macOS 15.7.5, without editing them or loading, unloading, or restarting any service.
| Field | What we read in the mDNSResponder daemon plist |
|---|---|
| Folder | /System/Library/LaunchDaemons |
| Filename | com.apple.mDNSResponder.plist |
| Label | com.apple.mDNSResponder.reloaded |
| UserName | _mdnsresponder |
| Executable argument | /usr/sbin/mDNSResponder |
This is a configuration observation, not a runtime permission audit. It establishes that this system daemon definition explicitly names a service account. It does not prove the effective privileges of every process on another Mac.
The example also exposes a second trap: the filename and Label were different. Searching for a process using only the plist filename can send you in the wrong direction. Record the Label and executable separately.
For contrast, the Finder agent definition we inspected was in /System/Library/LaunchAgents, with the Label com.apple.Finder and an executable inside Finder.app. We did not infer a daemon's behavior from an agent's folder or vice versa.
Use a small evidence checklist
When you find an unfamiliar entry, collect these details before deciding what to do:
- Location and type. Is it an agent, a daemon, or an app-bundled helper definition?
- Label and executable. Read the actual fields; do not assume that every name is identical.
- App relationship. Match the executable path and developer information to an installed app when possible.
- Current state. Check whether the process is running now, separately from whether a configuration file exists.
- Your need for the feature. Determine what would stop working before disabling or uninstalling anything.
For a plist you have identified, plutil -p "/path/to/item.plist" is a read-only way to display its fields. Replace the placeholder with the real path and retain the quotes. The command does not launch the helper.
For the separate runtime question, use the walkthrough on why a LaunchAgent plist may not be running. It distinguishes a file on disk, a registered job and an active process. Repeating that check for the exact label is more informative than treating every file as an active task.
If you decide the app is no longer needed, prefer its documented uninstall procedure. If you only want to change a supported background feature, start with the app's settings or the corresponding macOS control. The agent-versus-daemon distinction tells you what context to investigate; the app's purpose and your observed evidence should guide the decision.
