Disclosure: this site has a commercial relationship with CleanMyMac, developed by MacPaw. This article covers system administration performed with macOS’s own tools; no third-party utility is presented as a solution, because the correct tools here are launchctl and Finder.
Key takeaways:
- launchd starts and supervises everything on a Mac. Agents run for a logged-in user; daemons run system-wide before login.
- Five locations hold these items. Risk increases with each level — your user folder is yours; the System folder is not.
- An agent is a separate file from the app it starts, which is why software keeps running after you delete it.
- Read the plist before touching anything: Label identifies the vendor, ProgramArguments shows what actually runs.
- Disable first, delete later. A disabled item is restored in seconds; a deleted one is not.
- Agents are a normal mechanism and also the standard persistence method for unwanted software. Presence proves nothing either way.
What launchd is
Every process on a Mac traces back to launchd. It is the first thing that starts and the thing responsible for starting almost everything else — system services, background processes, and the software that runs when you log in.
launchd works from configuration files rather than from a startup script. Each file describes one item: what to run, when to run it, and under what conditions to restart it. Those files are property lists, and reading them is most of what an audit consists of.
This design is why software can persist through an application’s deletion. The configuration file and the application are separate things, and removing one does not remove the other.
Agents and daemons
The distinction is about privilege and context rather than about function.
An agent runs on behalf of a logged-in user. It has access to that user’s session, can display interface elements, and can reach that user’s files. It starts when the user logs in and stops when they log out. Software that needs to show you something — a sync client’s menu bar icon, an updater that prompts you — runs as an agent.
A daemon runs at the system level. It starts before anyone logs in, keeps running when nobody is logged in, and has no access to a user session or interface. Software that needs to work regardless of who is using the machine — a network filter, a backup service, a virtualization backend — runs as a daemon.
The practical consequence is asymmetric risk. A broken agent inconveniences one user and is trivially recoverable. A broken daemon can affect the machine’s ability to start, and recovery may require booting from something else.
The five locations
Items live in five places, ordered here by increasing risk of touching them.
| Location | Scope | What lives there | Your business? |
|---|---|---|---|
~/Library/LaunchAgents | Your account only | Agents installed by apps you run | Yes — this is the one you audit |
/Library/LaunchAgents | All users | Agents installed system-wide, usually by package installers | With care and attribution |
/Library/LaunchDaemons | System | Third-party system services: security software, VPNs, virtualization, backup tools | Audit yes, delete no |
/System/Library/LaunchAgents | macOS | Apple’s own user-level services | No — protected by SIP |
/System/Library/LaunchDaemons | macOS | Apple’s own system services | No — protected by SIP |
The two System locations are protected by System Integrity Protection and cannot be modified without disabling it. That protection is doing its job, and the correct response to encountering it is to stop rather than to look for a way around.
Note also that this list does not cover everything that runs at startup. Applications can register login items and background items through a separate mechanism surfaced in System Settings, and modern software increasingly uses that route rather than dropping files into LaunchAgents. A complete picture requires looking at both.
Listing what is loaded
To see what launchd currently has running:
launchctl listThe output has three columns: process ID, last exit status, and label. A numeric PID means the item is running right now. A dash means it is loaded but not currently running, which is normal for items that run on a schedule or in response to an event.
The middle column is the one worth reading carefully. A non-zero exit status means the item failed the last time it ran. An item repeatedly failing is worth investigating — it may be residue from software that no longer exists, trying and failing to start something that has been deleted.
To see the files themselves rather than what is loaded:
ls -la ~/Library/LaunchAgents
ls -la /Library/LaunchAgents
ls -la /Library/LaunchDaemonsComparing these two views is informative. A file present but not loaded is disabled or failing. An item loaded but with no corresponding file in the user-writable locations belongs to the system.
Reading a plist
This is the part that turns a list of identifiers into an actual audit.
cat ~/Library/LaunchAgents/com.example.updater.plistOr, for a binary plist that does not display as text:
plutil -p ~/Library/LaunchAgents/com.example.updater.plistFour keys carry most of the meaning.
| Key | What it tells you |
|---|---|
Label | The item’s identifier. Reverse-domain naming usually reveals the vendor. |
ProgramArguments | The executable that actually runs, plus its arguments. The most informative field. |
RunAtLoad | Whether it starts immediately when loaded. |
StartInterval / StartCalendarInterval | Whether it runs on a schedule, and how often. |
Other keys appear regularly: WatchPaths starts the item when a file or folder changes, KeepAlive restarts it whenever it exits, and QueueDirectories triggers it when a directory receives content.
KeepAlive deserves particular attention during an audit. An item with it set will be restarted by launchd every time it stops, which is why simply killing a process in Activity Monitor achieves nothing durable — launchd starts it again immediately.
Attributing an item to software
The audit question is always the same: what installed this, and do I still use that software?
Start with the label. Reverse-domain identifiers usually name the vendor directly, and searching for the identifier will typically identify the product.
Then check the executable path in ProgramArguments. If it points inside an application bundle in your Applications folder, the item belongs to software that is still installed. If it points to a path that no longer exists, the item is residue from something removed — and it is probably failing on every attempt, which the exit status column will confirm.
Executable paths pointing somewhere unusual deserve a closer look. Legitimate software generally runs from an application bundle or from a standard support location. An executable in a temporary directory, a hidden folder, or a location unrelated to any application you recognize is worth investigating before anything else.
Disabling rather than deleting
The safe sequence at every level is the same: disable, observe, and only then consider removal.
launchctl bootout gui/$(id -u)/com.example.updaterThis unloads a user agent for the current session. To prevent it loading at the next login, move the file out of the LaunchAgents folder rather than deleting it — your Desktop is a fine temporary destination.
Then use the machine normally for several days. If nothing breaks, the item was not needed. If something stops working, moving the file back restores it in seconds.
This sequence costs a few days and eliminates nearly all of the risk in the exercise. Deleting first and diagnosing later inverts that trade badly.
/Library/LaunchDaemons, treat audit and removal as separate activities. Identifying what is there is useful and safe. Removing a daemon belonging to security software, a VPN, or a virtualization product can leave network filters or kernel-level components active with nothing managing them, and removing one belonging to macOS can prevent the machine from starting.
This article deliberately does not provide copy-paste removal commands for system-level items. If a daemon belongs to software you want gone, use that vendor’s uninstaller — it knows what else it installed. If you cannot identify a daemon at all, that is a reason to investigate, not a reason to delete.
Items that reappear
Some items restore themselves after removal, and the cause is usually mundane.
The application is still installed and reinstalls its agent on launch — the correct fix is uninstalling the application properly, which is covered in the companion uninstallation guide.
Or a second item is responsible for maintaining the first, which is common with software that includes an updater component. Auditing the full set rather than one item at a time reveals this.
Or the item belongs to something you did not knowingly install. Persistence through reinstallation is the behavior that distinguishes unwanted software from merely unnecessary software, and at that point the question becomes what installed it rather than how to remove this particular file.
Security signals worth knowing
Launch agents are a normal, documented mechanism used by a large amount of ordinary software. Their presence is not suspicious in itself, and a Mac with a dozen agents from software you recognize is entirely typical.
Three signals justify a closer look, and they matter most in combination:
- An identifier that does not correspond to anything you installed, and does not resolve to a known vendor when searched.
- An executable path outside a normal application bundle — a hidden directory, a temporary location, a path with a randomized name.
- An item that returns after being removed, particularly when you cannot identify what is restoring it.
Any one of these has innocent explanations. Together they describe the standard persistence pattern for unwanted software on macOS, and the appropriate next step is a scan with CleanMyMac or other reputable security software rather than a manual deletion — because if something is maintaining that agent, removing the agent alone accomplishes nothing.
What this won’t fix
Auditing launch items tells you what starts automatically and lets you stop things you do not need. It is not a performance technique in itself: a handful of idle agents consume negligible resources, and disabling them will not make a slow Mac fast. The performance question is diagnosed differently, and the companion guide on post-update slowness covers that.
It also does not cover everything that runs at startup. Login items and background items registered through System Settings are a separate mechanism with its own interface, and a complete picture requires reviewing both. Nor does an audit remove software — it stops it starting, which is a different thing from uninstalling it.
Frequently asked questions
What is the difference between a launch agent and a launch daemon?
An agent runs on behalf of a logged-in user, with access to that session — it can show windows and reach the user’s files. A daemon runs at the system level, starts before login, and continues regardless of who is using the machine. Daemons are consequently more powerful and more dangerous to modify: a failed agent inconveniences one user, while a broken daemon can affect startup itself. Both are managed by launchd, which starts and supervises everything on a Mac.
Where are launch agents stored on a Mac?
Five locations, differing in ownership and risk. Your user LaunchAgents folder holds items for your account only. The system-wide LaunchAgents and LaunchDaemons folders in the top-level Library hold items installed for all users, typically via package installers. Two further locations inside the System folder belong to macOS and are protected by SIP. Items in your own folder are yours to manage; the deeper you go, the more likely you are to find something the system depends on.
Why does an app keep starting after I deleted it?
Because the agent that starts it is a separate file from the application, and deleting one does not remove the other. Agents load at login regardless of whether the software they reference still exists, and some reinstall components they find missing. This is the most common cause of software that survives removal. Locate the agent whose identifier matches, disable it, and restart — an agent already in memory keeps running until the session ends whatever happened to its file.
Is it safe to delete launch agents?
Items in your own user folder are generally safe once you have confirmed what they belong to, since the worst realistic outcome is a feature of an installed app breaking. System-level daemons are a different matter and should not be removed on the basis of a web guide, this one included. The safer approach at every level is to disable first and observe for a few days — a disabled item is restored in seconds, a deleted one is not.
How do I find out what a launch agent actually does?
Read its plist. The Label field gives the identifier, whose reverse-domain naming usually reveals the vendor. ProgramArguments shows the executable and its arguments, which is the most informative part. Other keys indicate when it runs — at load, on a schedule, when a path changes. An executable path pointing somewhere unexpected, or an identifier matching nothing you installed, is worth investigating before you do anything else.
Are launch agents a security concern?
They are a legitimate mechanism used by ordinary software, so presence alone means nothing. They are also the standard persistence method for unwanted software, since an agent is the simplest way to ensure something runs after every restart. Worth attention: an identifier matching nothing you installed, an executable outside a normal application bundle, and an item that reappears after removal. None confirms a problem alone; together they justify a closer look.
