Choose a LaunchAgent or LaunchDaemon

launchd runs jobs in two contexts, and choosing the wrong one produces confusing failures. A LaunchAgent runs for a logged-in user. It can work with that user’s files and session: the home folder, the user Keychain, the GUI. A LaunchDaemon runs in the system context and must not depend on a graphical user session. Daemons exist for machine-wide services that run before, or without, anyone logging in.

Location decides which one you get:

~/Library/LaunchAgents/     agents for this user only
/Library/LaunchAgents/      agents for every user who logs in
/Library/LaunchDaemons/     system daemons, run as root by default

The /System/Library equivalents belong to macOS itself. Leave those alone.

Personal automation belongs in ~/Library/LaunchAgents. Sorting screenshots, tidying project folders, backing up your own data: all of it is user-scoped work on user-scoped files.

The two contexts also live in different launchd domains, which matters for every command later in this module:

launchctl print gui/$(id -u) | head    # your user's GUI domain
sudo launchctl print system | head     # the system domain

Here is the trap this lesson exists to prevent. Your agent fails with a permission error, and you notice that a daemon running as root would make the error disappear. Do not turn it into a root daemon to work around a path or permission mistake. That trade swaps a visible error for a job with maximum privilege that cannot see your login session, has no access to your user Keychain, and may run while nobody is logged in to notice it misbehaving. One wrong path in a root job can damage files no user-level bug could touch.

Decide on paper first. Write down the required user, files, network access, and trigger. Choose the narrowest context that satisfies them. If the answer involves your home directory or anything tied to your session, it is an agent — and the fix for the permission error is fixing the permission.