When a macOS Login Item Looks Suspicious

A weird Background Item name is not the same thing as active malware. The work is to separate a real runnable daemon from stale macOS bookkeeping.

Simple Version

Think of macOS Login Items like a school attendance sheet. Some names on the sheet are real people in the room. Some names are old entries that the office forgot to erase.

In this case, the visible item said TNT - why join the navy if you can be a pirate. The real backing item was a CleanMyMac helper:

/Library/LaunchDaemons/com.macpaw.CleanMyMac4.Agent.plist
/Library/PrivilegedHelperTools/com.macpaw.CleanMyMac4.Agent

After those two files were deleted, the important part was gone: there was no daemon file and no privileged helper executable left at those paths. macOS could still show the old row because its Background Items database can keep stale records.

1. IdentifyFind the plist and helper behind the scary name.

2. RemoveDelete the actual runnable daemon files.

3. VerifyCheck launchctl, package receipts, filenames, and logs.

4. TraceWatch for recreation before assuming persistence.

Deeper Version

macOS has more than one system involved here. launchd runs agents and daemons. Background Items shows a user-facing view of apps and helpers that can run in the background. sfltool dumpbtm dumps that Background Task Management database.

A suspicious entry can therefore exist in three different forms:

Runnable persistence: a real plist in /Library/LaunchDaemons or ~/Library/LaunchAgents.
Privileged helper: an executable in /Library/PrivilegedHelperTools.
Stale record: a cached entry in macOS Background Items with no backing file.

The first two matter most. A stale record is annoying and suspicious-looking, but it cannot run by itself without a real file or another process recreating that file.

What Was Checked

launchctl print system and launchctl print gui/501 no longer showed a loaded MacPaw or CleanMyMac daemon.
The original plist and privileged helper paths returned “not found.”
Targeted searches found no remaining CleanMyMac daemon files under common system and user Library paths.
Package receipts, Spotlight filename search, and logs did not show an active CleanMyMac install trace.
The only MacPaw filename hits found were image assets inside Setapp, which is made by MacPaw and is not itself evidence of that daemon.
A short root filesystem trace did not catch any process recreating or touching the removed daemon paths.

How to Trace a Reinstaller

If the daemon comes back, the useful question is not “is there a scary name?” It is “which process wrote the plist or helper back onto disk?”

sudo fs_usage -w -f filesys | grep -i -E 'macpaw|cleanmymac|com\.macpaw\.CleanMyMac4\.Agent'

That catches activity while it happens. If nothing recreates the file during the trace window, the log may be quiet. For stronger evidence, run the trace during login, while launching Setapp, or right after the stale Login Items row reappears.

Safer Mental Model

Do not treat every cache entry as malware, and do not treat deletion as proof of safety. The strongest evidence is a chain: file exists, launchd loads it, process runs, trace shows who created it.

The Password-Theft Angle

It is reasonable red-team thinking to ask whether a malicious process could notice cleanup activity and steal the admin password when root commands are run.

The answer is: seeing commands like sfltool, launchctl, or fs_usage is not enough to read the password typed into a real macOS administrator prompt. Password theft usually needs something stronger first: Accessibility access, Input Monitoring, Screen Recording plus deception, a fake prompt, an already-root process, or a compromised shell/session.

The next privacy audit should check Accessibility, Input Monitoring, Screen Recording, Full Disk Access, and Profiles / Device Management for unknown entries.

When to Reset Background Items

sfltool resetbtm can clear stale Background Items records, but it resets the whole Background Task Management database. Real apps usually re-register their helpers later, but prior allow/deny choices may be forgotten and “Background Items Added” notifications may reappear.

Use it only when the stale row is worth that churn. If the backing daemon files are gone and no trace shows recreation, waiting through a logout or restart is the lower-impact first move.