How to Find Hidden Apps on Mac That You Didn't Install

The first thing I do on any new Mac is check what's in ~/Library/LaunchAgents. It's shocking what ends up there after a few months of installing software. Helper apps, updater daemons, sync agents — things you never asked for that quietly installed themselves alongside software you actually wanted.

Most people think of "apps" as the icons in their Applications folder or Dock. But macOS has a much broader definition. An app can be a background-only agent with no icon, no window, and no Dock presence. It can live in a folder you've never opened. It can start at boot and run forever without you knowing.

Here's how to find every app on your Mac — the visible ones, the hidden ones, and the ones that probably shouldn't be there.

The obvious places (that still surprise people)

You already know about /Applications. That's where most apps live. But did you know there's a second Applications folder?

ls /Applications/
ls ~/Applications/

The first is the system-wide Applications folder. The second is your user-specific one. Apps installed from the Mac App Store sometimes land in ~/Applications, and some third-party installers put things there too. Most people never check it.

There's also /System/Applications/, which houses Apple's built-in apps — Calculator, Preview, TextEdit, all the ones that ship with macOS. You can't modify this folder thanks to System Integrity Protection, but it's worth knowing it exists.

Here's a quick count of how many .app bundles are on your entire system:

mdfind 'kMDItemContentType == "com.apple.application-bundle"' | wc -l

Run that. I'll wait. On my main Mac, I get over 400. That number includes apps nested inside other apps (helper apps, embedded frameworks, Xcode components if you have it installed), so don't panic. But it's probably a lot more than you expected.

Using mdfind to hunt down every application bundle

Spotlight's mdfind command is genuinely one of the most underrated tools on macOS. It searches the Spotlight index, which means it's fast and covers your entire disk.

To list every application bundle on your Mac:

mdfind 'kMDItemContentType == "com.apple.application-bundle"'

That'll spit out a long list. Too long to read through manually. Let's narrow it down. To find apps that aren't in the standard locations:

mdfind 'kMDItemContentType == "com.apple.application-bundle"' | grep -v '/Applications/' | grep -v '/System/' | grep -v '/Library/Apple/'

This filters out everything in the normal folders and shows you apps living in unusual places. You might find .app bundles sitting in ~/Downloads (stuff you ran once and forgot about), /usr/local/, or nested deep in ~/Library. Those are the interesting ones.

To find apps added recently — say, in the last 7 days:

mdfind 'kMDItemContentType == "com.apple.application-bundle" && kMDItemFSCreationDate > $time.today(-7)'

That date filter is handy if you suspect something was installed without your knowledge.

The real hiding spots: LaunchAgents and LaunchDaemons

If I had to pick the single most important place to check on any Mac, it's the LaunchAgents and LaunchDaemons directories. This is where background software registers itself to start automatically — and it's where a concerning amount of unwanted software hides.

There are four directories that matter:

ls ~/Library/LaunchAgents/
ls /Library/LaunchAgents/
ls /Library/LaunchDaemons/
ls ~/Library/LaunchDaemons/

The first one — ~/Library/LaunchAgents/ — is the one I check religiously. Any app you've installed can drop a plist file here, and it'll run every time you log in. No confirmation. No notification. It just runs.

The /Library/LaunchAgents/ and /Library/LaunchDaemons/ directories require admin access to modify, so anything here was installed by an app that asked for your password at some point. LaunchDaemons are more powerful than LaunchAgents — they run as root and start at boot, even before you log in.

The ~/Library/LaunchDaemons/ directory usually doesn't exist on most Macs, but check anyway. Malware occasionally creates it.

Each plist file in these directories defines a background job. Open one to see what it actually does:

cat ~/Library/LaunchAgents/com.example.helper.plist

Look at the ProgramArguments key. That tells you the exact binary it's running. If the path points to something in /Applications/SomeApp.app/Contents/MacOS/, it's probably a legitimate helper for an app you installed. If it points to something in /tmp or a random path in your home directory, that's suspicious.

Background-only apps and invisible helpers

Some apps on your Mac have no icon, no Dock presence, and no visible windows. They're designed to run entirely in the background. These are called "background-only" apps — their Info.plist contains LSUIElement set to true (or the newer LSBackgroundOnly), which tells macOS to hide them from the Dock and the Cmd+Tab switcher.

Many of these are legitimate. Dropbox's helper, Spotify's helper, 1Password's browser extension bridge — they all run this way. But it's also how potentially unwanted software stays out of sight.

To find background-only apps currently running:

ps aux | grep -i '\.app/Contents/MacOS' | grep -v grep

That shows every process running from inside an .app bundle. Cross-reference this with what you see in your Dock and you'll probably spot a few you didn't know about.

A more targeted approach using launchctl:

launchctl list | grep -v 'com.apple'

This shows every loaded launch job that isn't an Apple system service. If you see entries you don't recognize, note the label and look it up. You can get more details with:

launchctl print gui/$(id -u)/com.example.suspiciousagent

Replace com.example.suspiciousagent with the actual label. This shows you the full job definition, including what binary it runs, when it was last started, and its current state.

Checking for apps that came with other apps

Bundleware is a real problem on macOS. You install one app, and it quietly installs two or three others. This was rampant back in the Yosemite/El Capitan era, and while Apple's notarization requirements have reduced it, it still happens.

Common culprits include free video converters, torrent clients, and "Mac cleaner" utilities. They'll bundle browser extensions, search engine changers, or persistent background agents alongside the app you actually wanted.

Here's a practical way to find recently installed apps by modification date:

find /Applications -maxdepth 2 -name "*.app" -mtime -30

That shows apps in /Applications modified in the last 30 days. If something shows up that you don't remember installing, investigate it.

You can also check what's registered as a login item through the system:

osascript -e 'tell application "System Events" to get the name of every login item'

I should give an honest counterpoint here: not every unfamiliar app is a threat. macOS itself installs helper apps and agents that look unfamiliar. Processes like com.apple.bird, com.apple.cloudd, or com.apple.suggestd are legitimate Apple services with non-obvious names. Before you delete something, always search for its name online. The last thing you want is to remove a system component and break something.

Using Activity Monitor (the right way)

I always tell people: before you install any security tool, learn to use Activity Monitor. It won't catch everything, but it teaches you what "normal" looks like on your machine.

Open it from Applications > Utilities > Activity Monitor. But don't just look at the CPU tab. Switch to the Network tab and sort by "Sent Bytes." Background apps that are phoning home or syncing data will show up here even if they're invisible everywhere else.

Then check the Disk tab. Apps that are scanning your files, indexing, or exfiltrating data will show disk activity even if they aren't using much CPU.

Here's the thing most guides miss: Activity Monitor shows processes, not apps. A single hidden app might spawn three or four processes. To trace a process back to its parent app, double-click it in Activity Monitor and look at the path under "Open Files and Ports." Or from Terminal:

ps aux | grep [P]rocessName

Replace ProcessName with whatever you see in Activity Monitor. The path in the output tells you where the binary lives on disk.

The /Library folder deep dive

Beyond LaunchAgents and LaunchDaemons, there are several other /Library subdirectories where hidden software can live:

ls /Library/PrivilegedHelperTools/

This is where apps install helper tools that run with elevated privileges. VPN software, virtualization tools like Parallels, and security software commonly use this. But if you see something here from an app you uninstalled months ago, the helper might still be hanging around.

ls /Library/StartupItems/

StartupItems is a legacy mechanism from pre-Leopard macOS. It should be empty on any modern system. If it's not, whatever's in there is either very old or deliberately using an obscure persistence method.

ls ~/Library/Application\ Support/

This is worth a browse. Every app stores data here, and it's where you'll find remnants of uninstalled apps. A folder here for an app that's no longer on your Mac means something was left behind — configuration files, databases, sometimes even executable code.

Checking code signatures

Once you find an unfamiliar app or binary, the next step is checking whether it's properly signed. macOS requires apps to be code-signed and ideally notarized by Apple. Unsigned or improperly signed code is a red flag.

codesign -dv --verbose=4 /path/to/suspicious.app

Look at the Authority lines. Legitimate software from known developers will have a chain like:

Authority=Developer ID Application: Company Name (XXXXXXXXXX)
Authority=Developer ID Certification Authority
Authority=Apple Root CA

If you see "code object is not signed at all" or the team identifier doesn't match who you'd expect, be cautious.

You can also check Gatekeeper's opinion:

spctl --assess --type execute -v /path/to/suspicious.app

If Gatekeeper rejects it, macOS wouldn't have let you open it normally (unless you explicitly overrode the warning). But apps installed before you upgraded macOS versions can sometimes slip through.

Putting it all together: a practical sweep

Here's my actual workflow when I want to do a thorough check on a Mac. When I was testing CoreLock's process scanner, I learned more about macOS internals in three months than I did in years of using a Mac. But the manual version goes like this:

Step 1: Run the mdfind command to count total app bundles. Note the number.

mdfind 'kMDItemContentType == "com.apple.application-bundle"' | wc -l

Step 2: List everything in LaunchAgents and LaunchDaemons. Open any plist files you don't recognize and check the ProgramArguments.

ls ~/Library/LaunchAgents/ /Library/LaunchAgents/ /Library/LaunchDaemons/ 2>/dev/null

Step 3: Check running processes against what you expect. Sort by name and look for anything unfamiliar.

ps aux --sort=command | less

Step 4: Verify code signatures on anything suspicious.

codesign -dv --verbose=4 /path/to/suspicious.app

Step 5: Check network connections. If a hidden app is communicating with external servers, this is where you'll catch it.

lsof -i -P | grep ESTABLISHED

That's a lot of terminal work. Honestly, I do this manually maybe once a quarter on my personal machine. For day-to-day monitoring, I use CoreLock — it does all of this automatically and flags anything unusual. But knowing how to do it manually means you understand what your security tools are actually checking, and you can verify their findings when something seems off.

Removing what you find

If you've found something that shouldn't be there, removing it depends on what it is.

For apps in /Applications or ~/Applications: Move them to Trash, then check ~/Library/Application Support/, ~/Library/Preferences/, and ~/Library/Caches/ for leftover folders matching the app name. Delete those too.

For LaunchAgents: First, unload the agent so it stops running:

launchctl bootout gui/$(id -u)/com.example.suspiciousagent

Then delete the plist file. If it's in ~/Library/LaunchAgents/, you can delete it directly. If it's in /Library/LaunchAgents/ or /Library/LaunchDaemons/, you'll need sudo.

For PrivilegedHelperTools: These require admin access to remove:

sudo rm /Library/PrivilegedHelperTools/com.example.helper

After removing anything, restart your Mac and verify it's gone. Check Activity Monitor and re-run the LaunchAgents listing to confirm nothing reinstalled itself.

macOS Sequoia and Ventura differences worth knowing

Sequoia (macOS 15) tightened things up compared to earlier versions. The Background Items notification — where macOS alerts you when something registers a login item — was introduced in Ventura (13) and improved in Sonoma (14). On Sequoia, these notifications are more reliable and harder to suppress.

If you're running Ventura or later, go to System Settings > General > Login Items and check both the "Open at Login" section and the "Allow in the Background" section. The second one is easy to miss but shows you background agents that are loaded even though they don't appear as traditional login items.

On older systems (Monterey and before), you won't get these notifications at all. That means apps can register LaunchAgents silently, and the only way to find them is to check the directories manually. If you're still on an older macOS version, checking LaunchAgents regularly is even more important.

The realistic takeaway

Your Mac has more hidden software on it than you think. Most of it is harmless — helper apps for software you use, Apple system services, updater agents. But some of it is leftover junk from apps you uninstalled, and occasionally it's something you genuinely never asked for.

The commands in this guide work on any Mac running macOS Ventura or later. Build a habit of checking your LaunchAgents folder every few months. Keep an eye on your login items. And when you find something unfamiliar, look it up before you delete it — breaking a legitimate system service is worse than leaving a harmless helper running.

Your Mac is remarkably good at protecting itself at the system level. SIP, Gatekeeper, XProtect — Apple's built-in defenses handle a lot. The gap is at the application layer, where software you chose to install can embed itself deeper than you realized. Close that gap, and you're ahead of most people.