Have you noticed osqueryd hogging your CPU cycles, or perhaps you’re trying to clean up a Mac before passing it on, only to find a stubborn background process that won’t quit? You’re not alone. Many users and system administrators discover that how to remove osqueryd is a common search query when they want to reclaim system resources or ensure a truly clean state before resale or repurposing.
Unlike standard applications that can be dragged to the Trash, osquery operates as a low-level security agent often managed by launchd. Simply killing the process in Activity Monitor is temporary; without unloading the service via macos launchctl and deleting the underlying configuration files, it will resurrect itself on the next boot. In my years managing enterprise Mac fleets, I’ve learned that a "clean" removal requires a three-phase approach: stopping the service, stripping the files, and verifying that no residual data remains to trigger future security alerts. This guide walks you through uninstalling both Homebrew-managed and manually installed versions, ensuring you leave no stone unturned.
Pre-Check: Identify How osquery Was Installed
Before you run any rm commands, you need to know who put osquery on your machine. The method of uninstallation differs slightly depending on whether it was installed via a package manager, a manual shell script, or pushed by an MDM (Mobile Device Management) solution like CrowdStrike or Palo Alto.
Checking for Homebrew or Manual Installation
I always start by checking if Homebrew is the source of truth. Open Terminal and type brew list osquery. If this returns a version number, you’re dealing with a package-manager installation, which makes cleanup easier. However, many corporate environments use manual scripts. To check for these, look for the presence of /Library/LaunchDaemons/com.facebook.osqueryd.plist. If this file exists but Homebrew doesn’t recognize the package, it was likely installed manually or by an MDM agent.
It’s also worth checking for MDM enrollment. Run profiles list to see if any profiles are forcing the installation of security agents. If you find a plist file but no Homebrew package, you’ll need to handle the removal manually. This distinction is crucial because an MDM might simply reinstall the agent if you delete it without disabling the policy first. In my experience, ignoring the MDM source is the most common reason for "permanent" removals failing—the agent just comes back after a reboot.
Step-by-Step: Stop and Unload the osquery Daemon
You cannot safely delete the files while the daemon is actively running. Think of it like trying to change the tire on a moving car; you need to stop the vehicle first. This phase focuses on using launchctl to gracefully (or forcefully) stop the service.
Using launchctl to Unload the Service
The heart of macOS service management is launchctl. To stop osquery, you must unload the specific plist file that dictates its behavior. Most installations use a system-level daemon, which requires administrative privileges.
Run the following command to unload the service:
sudo launchctl unload /Library/LaunchDaemons/com.facebook.osqueryd.plist
If you encounter a "Permission denied" error, ensure your user account is an administrator. The sudo prompt will ask for your password. I’ve noticed that on newer versions of macOS, if the service was loaded at boot, you might also need to run sudo launchctl bootout system /Library/LaunchDaemons/com.facebook.osqueryd.plist if the standard unload command gives you a warning about the service still being active. This specific command detaches the service from the launchd manager more thoroughly.
Killing Residual Processes
Even after unloading the plist, a zombie process might linger. To verify if the process is still running, use pgrep osqueryd.
If a PID (Process ID) is returned, the process is still alive. You can try a polite termination first:
sudo kill $(pgrep osqueryd)
Wait ten seconds, then run pgrep osqueryd again. If it persists, you need to force terminate it. This is the "last resort" step:
sudo kill -9 $(pgrep osqueryd)
When I troubleshoot stuck daemons, I find that kill -9 is almost always necessary if the process has crashed in a bad state. Once pgrep returns no output (and exits with a non-zero status code implicitly), the process is gone, and you are safe to delete the files.
Critical Files: Delete Plists, Logs, and Binaries
Now that the process is stopped, we move to the actual data removal. This is where we prevent the agent from reloading on restart and clean up the local database that might contain sensitive system information.
Removing Launch Agents and Daemons
There are two locations where launchd looks for startup scripts: /Library/LaunchDaemons (system-wide, root) and /Library/LaunchAgents (user-specific). Osquery is typically a daemon, but some custom setups might use agents.
- Delete the primary daemon plist:
sudo rm /Library/LaunchDaemons/com.facebook.osqueryd.plist - Check for user-level agents:
ls /Library/LaunchAgents | grep -i osqueryIf any files are listed, remove them withsudo rm /Library/LaunchAgents/[filename].
Understanding the difference is vital. LaunchDaemons run as root and handle system-level tasks. LaunchAgents run as the logged-in user. By deleting both, you ensure that no part of the osquery ecosystem can trigger a reload. I always double-check the LaunchAgents folder because it’s a common hiding spot for user-specific modifications that system admins might overlook.
Cleaning Up Configs and Databases
This step is critical for privacy. Osquery stores its local database, which caches system state information, in a specific directory. If you’re selling the Mac, you must wipe this.
The following directories contain the configuration and data:
/private/var/osquery– The main data directory, including the local database./private/var/log/osquery– Log files./usr/local/bin/osquery*– The actual executable binaries.
Run these commands to remove them:
sudo rm -rf /private/var/osquery
sudo rm -rf /private/var/log/osquery
sudo rm /usr/local/bin/osquery*
If you installed via Homebrew, you should also run brew uninstall osquery to clean up the cellar links, although the manual removal above covers the system files. I find that running the manual rm commands even after a brew uninstall is a good safety net, as package managers sometimes leave dangling symlinks or configuration files in /usr/local.
Verification: Confirm osqueryd is Fully Removed
Did you delete the files? Yes. But did the system stop tracking them? This is the final polish that distinguishes a professional cleanup from a sloppy one.
The Cleanup Checklist
To ensure the package is permanently removed from the system’s inventory, you need to interact with pkgutil. This tool keeps track of installed packages. If you don’t clear this record, it can cause confusion in future audits or reinstall attempts.
Run this command to forget the package:
sudo pkgutil --forget com.facebook.osqueryd
Note: If you installed via Homebrew, this command will likely fail or be unnecessary, as Homebrew manages its own registry. It is primarily for manual .pkg installs.
Next, perform a final sweep to catch any stray files. Use the find command to search the likely locations:
sudo find / -name "*osquery*" 2>/dev/null
This might take a minute. If it returns files in /Applications or /tmp, review them manually. Finally, restart your Mac. Upon reboot, check Activity Monitor or run ps aux | grep osquery. If nothing appears, you have successfully achieved a clean state. I always perform this restart test immediately; it’s the only way to be 100% sure that no other watchdog process is trying to respawn the daemon.
Troubleshooting: Common Errors and High CPU Issues
Sometimes, the removal process hits a snag, or the reason you want to remove it is because it’s misbehaving. Here is how to handle the tricky scenarios.
Fixing 'Permission Denied' and Dependency Errors
If you encounter "Operation not permitted," System Integrity Protection (SIP) might be blocking you from modifying certain protected paths, though osquery files are rarely in the SIP-protected /System volume. More likely, you are trying to delete a file owned by root without using sudo. Ensure every rm and launchctl command is prefixed with sudo.
A more complex issue is dependencies. If other tools (like an EDR solution) rely on the osquery binary, deleting it might break those tools. Before you rm the binary, check if any other software reports errors. In my experience, if a third-party security tool is wrapping osquery, it’s safer to uninstall the wrapper tool first, then remove osquery. If the plist file is "locked," check its permissions with ls -l /Library/LaunchDaemons/com.facebook.osqueryd.plist. You may need to change ownership or permissions, though this is rare on standard installations.
Addressing 'osqueryd Process Stuck' Scenarios
If kill -9 doesn’t work, the process might be in an "Uninterruptible Sleep" (usually indicated by 'U' in the state column of ps). This usually happens when the process is waiting for a disk I/O operation that isn’t completing, often due to a corrupted database file.
In this case, deleting the database file (/private/var/osquery/osquery.db) before killing the process can sometimes allow the stuck I/O operation to fail and release the process. However, if your goal is simply to fix high CPU usage and you don't want to uninstall osquery entirely, consider a clean reinstall instead. Stop the service, delete the /private/var/osquery directory, and start the service again. This resets the local cache and often resolves performance issues without needing a full removal. If the process remains stuck after these steps, a reboot is the most reliable way to clear the state.
Frequently Asked Questions
Can I delete osqueryd without admin privileges?
No. System-level daemons in /Library/LaunchDaemons and binaries in /usr/local/bin require root access (sudo) to delete. While you might be able to delete user-level files in your home directory, a complete removal of the system agent always requires admin privileges.
Why is osqueryd using high CPU resources?
High CPU is often caused by a misconfigured log interval, a full local database causing heavy disk I/O, or a bug in a specific version of osquery. If the tool is no longer needed, removal is a valid fix. If it is needed, try clearing the local database (/private/var/osquery) and restarting the service.
Is it safe to delete osqueryd files manually?
Yes, provided you follow the correct order: stop the service (launchctl unload), kill the process, then delete the files. Deleting files while the process is running can cause temporary errors for any other system components that depend on it, but it will not corrupt the OS.
How to remove osqueryd launch agent after uninstallation?
If you've deleted the daemon but an agent persists, check /Library/LaunchAgents and ~/Library/LaunchAgents. Run ls ~/Library/LaunchAgents | grep osquery and delete any matching files with rm (no sudo needed for your own user folder). Some custom setups place user-level agents here, so this is a common oversight.
Conclusion
Removing osqueryd is less about a single command and more about a disciplined sequence: Stop, Remove, Verify. By identifying the installation source, using launchctl to gracefully detach the service, and purging the local database, you restore your Mac to a clean, predictable state. Don’t skip the verification step; running pkgutil --forget and a final find command ensures that no residual logs or tracking records remain, which is crucial for both privacy and system integrity.
One final caution: if your Mac is enrolled in a corporate MDM, it may automatically reinstall osqueryd to enforce security policies. In that case, consult your IT department before attempting permanent removal. For personal devices, this guide provides a complete checklist to leave no trace behind. I recommend saving this guide as a reference for future cleanups—whether you are offboarding a device or simply optimizing performance, a systematic approach always beats a guesswork one.