Login items on a Mac: what starts, what hides, and how to audit it
· 6 min read
A Mac that has been in use for a few years starts a surprising number of things at login, and the list in System Settings shows only part of it. Auditing the rest is worth doing occasionally, both for startup time and for knowing what is running.
The three places things start from
Login Items you added. System Settings, General, Login Items, top section, headed Open at Login. These are applications you or an installer added deliberately. You can remove them freely.
Background items apps registered. The same panel, lower section, headed Allow in the Background. This is where modern applications register helpers, updaters and daemons. The entries are often named after the developer rather than the app, which is why the list is hard to read.
Switching one off here stops it running. Some applications will re-register on next launch, which is a reasonable signal about whether the item is genuinely needed.
Launch agents and daemons. Property list files in specific folders, loaded by the system. These do not all appear in System Settings.
ls -1 ~/Library/LaunchAgents
ls -1 /Library/LaunchAgents
ls -1 /Library/LaunchDaemons
The first is per user, the second and third are system-wide. A typical machine has entries like com.adobe.GC.Invoker-1.0.plist or com.example.updater.plist. The name usually identifies the vendor.
To see what is actually loaded rather than merely present:
launchctl list | head -30
The first column is the process ID if it is running, the second is the last exit status, and the third is the label. A dash in the first column means it is registered but not currently running.
Reading a launch agent
If a name is unfamiliar, the file itself explains what it does:
cat ~/Library/LaunchAgents/com.example.updater.plist
Look for two keys. ProgramArguments shows the command being run, including its path, which tells you which application it belongs to. RunAtLoad and StartInterval show whether it runs at login and how often it repeats.
That is usually enough to decide whether you want it. A path under /Applications/SomeApp.app/ belongs to an app you have; a path pointing at something you removed months ago is a leftover.
Removing things safely
Work in order of reversibility.
System Settings first. Toggling an item off is reversible and obvious. Do this and restart before touching anything else.
Then unload a launch agent without deleting it, which is still reversible:
launchctl unload ~/Library/LaunchAgents/com.example.updater.plist
Only then move the file, to a folder rather than the Trash, so it can be put back:
mkdir -p ~/Desktop/disabled-agents
mv ~/Library/LaunchAgents/com.example.updater.plist ~/Desktop/disabled-agents/
Two cautions. Do not remove anything from /System, which macOS protects for good reason. And be careful with /Library/LaunchDaemons, which contains system-wide services that other things may depend on; a personal machine rarely needs anything removed from there.
The uninstalled-app leftovers
The common finding in an audit is agents belonging to applications you removed. Dragging an app to the Trash does not remove its launch agents, so they remain, fail to find their program, and quietly retry.
Cross-reference each agent’s ProgramArguments path against what is actually installed. Anything pointing at a missing path can go.
Why this matters for a time record
Two reasons, one obvious and one not.
The obvious one: a tracker that does not start at login records nothing until you notice, and macOS occasionally resets these registrations after an update. If a day’s record is missing its morning, this panel is the first place to look. When time tracking stops recording covers diagnosing that.
The less obvious one: everything in these lists is running while you work, and some of it is doing more than you would guess. If you are investigating battery or fan noise, this list is the population of suspects. Finding which menu bar app is using too much CPU covers narrowing it down.
Where Punchcard sits
Punchcard registers itself to start at login so the record covers the whole day rather than beginning whenever you remember. It appears in Allow in the Background and can be switched off there like anything else.
It installs no launch daemons, no helper processes and no updater running on a schedule. There is one application, and it has no networking code at all, so there is nothing checking for anything. An app with no networking code, and how to check covers verifying that rather than taking it on faith.
A worthwhile audit
Once a year, or after a machine has been migrated a few times:
- System Settings, General, Login Items. Read both lists. Remove what you do not recognise or want.
ls -1 ~/Library/LaunchAgents /Library/LaunchAgentsand read the names.- For unfamiliar ones,
catthe file and readProgramArguments. - Remove leftovers from applications you no longer have.
- Restart and confirm nothing you wanted is missing.
Startup time improves, and more usefully you end up knowing what is running on your own machine.
Questions
Why do some background items have no useful name?
They are named by bundle identifier, which is a developer’s naming rather than a product name. Searching the identifier usually resolves it, and the ProgramArguments path is more reliable.
Something I switched off came back. The application re-registered it on next launch. That is legitimate for a component the app genuinely needs. If it is an updater you do not want, the setting is usually inside the app.
Do login items slow down startup much? Individually, rarely. Collectively on a machine with twenty of them, noticeably. The gain from an audit is usually modest and the knowledge is worth more.
Is it safe to delete files from /Library/LaunchDaemons? Be cautious. Those run system-wide, often as root, and other software may depend on them. Unload first, restart, and confirm nothing broke before moving anything.