DaemonControl
Download
macOS app · free
launchd is what starts programs on your Mac at login, on a schedule, when a folder changes, and at boot. DaemonControl shows you all of it — and tells you why the one that stopped working stopped working.
Free · macOS 14+ · signed and notarized by Apple
Nothing here runs as root by default. DaemonControl is a front end for launchd, not a
replacement for it: it reads and writes the same jobs launchctl does.
See everything
Your own agents, Apple’s daemons, and the ones an app registered at runtime without leaving a file behind. Search by label, program or path; filter by running, failed, disabled or not loaded.
Per-user agents and system-wide daemons in the same list, so you are not guessing which of the several launchd domains a job lives in.
Jobs registered by an app at runtime never appear in the LaunchAgents folders. They appear here.
Running, failed, disabled, not loaded. The states that matter when you are looking for the thing that stopped.
Label, program or path — whichever part of it you can recall.
Understand it
Schedules are written out in words. Exit codes come with what they mean
rather than just a number. And every key in the file is documented in the
editor, next to the control that sets it — so you are not reading the
launchd.plist man page in another window.
The plist is still the truth. DaemonControl just stops you having to hold it in your head.
<!-- what launchd stores --> StartCalendarInterval { Hour: 9, Minute: 0, Weekday: 1 } StandardErrorPath /tmp/sync.err ThrottleInterval 10 // what DaemonControl shows At 09:00 on Mondays. Errors to /tmp/sync.err Waits 10s between restarts.
Fix it
That is the normal way a launchd job fails, and it is why they are miserable to debug. DaemonControl looks for the specific reasons, names the one it finds, and for most of them offers the fix.
Each finding says which job, which key and which line — and what to change. Most come with a one-click fix, because most of them have exactly one correct answer: an absolute path, a created folder, a corrected spelling.
The ones that do not — a crash loop, a permission macOS will not grant — are still explained, because knowing which of the two it is saves the afternoon.
Change it safely
Your own agents need no privileges at all. Neither does reading and diagnosing every job on the machine — the entire list, and the entire doctor, run with none.
Changing a system daemon asks for your password, once per change. If you would rather not be asked, there is a privileged helper to opt into, with a plain account of what it can do and a log of everything it has done.
From the terminal too
A daemoncontrol command line tool ships inside the app, with the
same list, doctor and control commands. There is an MCP server too, so an
agent can inspect and manage jobs the same way you would.
# everything that is not healthy $ daemoncontrol list --state failed # why this one does nothing $ daemoncontrol doctor com.example.sync Exit 127 — program not found on launchd's PATH fix: use /opt/homebrew/bin/rclone # and the usual controls $ daemoncontrol start com.example.sync
Every job on your Mac, the schedule in words, and the reason the broken one is broken.
Free · macOS 14+ · Apple silicon and Intel · signed and notarized
Questions
No. It reads and writes the same jobs launchctl does, in the
same places. Anything you change here is a normal launchd job afterwards, and
anything you made at the command line shows up here.
Not to read anything, and not to change your own agents. Changing a system daemon asks for your password once per change. The privileged helper is optional and off unless you turn it on.
It can do what launchctl can do, so treat Apple’s own daemons
with the same care you would there. The list marks which jobs are the
system’s, and nothing is changed without you asking for it.
No accounts, no servers, no analytics. It reads what is already on your Mac. The only network request it makes is the update check, and you can turn that off in the menu.
It lets an agent use the same list, doctor and control commands the CLI exposes — so “find out why my backup job stopped running” can be answered without you reading plists yourself.
I built DaemonControl with heavy use of AI coding tools.
Saying so seems more useful than leaving you to guess.