How to Uninstall Antivirus on Mac Without Breaking Your Network

UninstallPublished Updated 15 min read

An antivirus product is not one app. It is an app bundle plus a set of registrations macOS holds on its own side of the fence: a system extension, a saved network filter configuration, one or more launchd jobs, usually a privileged helper, and on a managed Mac a configuration profile. Dragging the bundle to the Trash removes the front end and leaves every registration in place. That is why this category has a reputation for being unremovable, and why the first move is the vendor's own uninstaller rather than Finder.

What a security product installs beyond the app bundle

You can inventory the whole surface read-only, on any Mac, in about a minute:

systemextensionsctl list
ls -la /Library/LaunchDaemons /Library/LaunchAgents ~/Library/LaunchAgents
ls -la /Library/PrivilegedHelperTools
profiles list
pkgutil --pkgs | grep -i vendorname

A system extension carries the code that inspects files and traffic, replacing the kernel extensions this software used to ship, which is why old advice about deleting a .kext no longer describes anything. Apple's system extension guide says where it lives: "System extensions reside inside your app's Contents/Library/SystemExtensions folder." Activating one requires your approval, which is why installing security software always involves a trip into Settings. Apple's deployment technote adds the property that matters at removal time: a provider packaged this way "runs in a global context, completely independent of the logged in user."

A network content filter or transparent proxy is a separate object, and it is the one that takes people's internet away. The configuration that turns it on belongs to the system rather than the app. NEFilterManager is explicit: "The filter configuration is stored in the Network Extension preferences which are managed by the Network Extension framework," and changes take effect only when the owning app explicitly saves them.

launchd jobs start the background pieces. /Library/LaunchDaemons runs as root at boot, before anyone logs in; /Library/LaunchAgents runs for every user at login; ~/Library/LaunchAgents runs for you. A plist in those folders is a registration with launchd, not an ordinary settings file.

A privileged helper under /Library/PrivilegedHelperTools is a root-owned executable paired with a daemon that should be unloaded before the file goes anywhere. A configuration profile, on a Mac deployed by an employer or school, carries the extension approvals and filter payloads so the software installs without prompting anybody, and the same mechanism can put it back.

One antivirus installer fanning out into an app bundle in Applications, a system extension inside that bundle, a network filter configuration held in Network Extension preferences, launch daemons and agents registered with launchd, a privileged helper tool, and a configuration profile.
Only the first of these is a file you can drag. The rest are registrations macOS holds, each with its own owner and its own removal path.

Why dragging it to the Trash cannot work

Apple documents one piece of good news, and it is narrower than it first reads: "The system automatically uninstalls any system extensions when the user deletes the corresponding app." That covers the extension inside the bundle, and says nothing about the other registrations, none of which are inside the bundle.

The filter configuration is behind the most common complaint here. It has its own lifetime in the Network Extension preferences, and Apple documents its removal as an explicit call the owning app makes. Deleting an app never makes that call. What remains is an enabled filter pointing at a provider that no longer exists, and the symptoms are the ones people report after a half-removal: DNS lookups that fail, a browser that hangs on every page, connections that time out while the Wi-Fi icon shows a full signal. The network is fine. Traffic is being handed to a filter that cannot answer.

The launchd jobs are the second failure. Deleting an executable does not deregister the job that starts it, it converts a working service into one that fails on every launch, and a job configured to stay alive gets retried in a loop, which is where the "my fan spins up after I uninstalled it" reports come from. Deleting the plist while the job is loaded is the mirror image: launchd keeps the job until the next reboot with nothing on disk behind it. The helper and the profile survive for the same reason, and a profile carrying a software payload will reinstall what you deleted.

The app bundle moved to the Trash while the network filter configuration, the loaded launch daemon, the privileged helper, and the configuration profile all survive it, producing DNS failures, a relaunch loop, and reinstalled software.
Every symptom of a half-removed security product traces back to a registration that outlived the file you deleted.

The difficulty is a design decision

Security software that any process could silently uninstall would be worthless, since the first thing capable malware would do is remove the thing watching it. So macOS puts both ends of the lifecycle where a background process cannot reach: activation needs a human clicking Allow in Settings (Apple's alert page points at Login Items & Extensions on macOS 15 and later, Privacy & Security before that), and deactivation is a request from the app that owns the extension. The friction is that design working, and there is no sequence of rm commands that is the real uninstall being kept from you.

The rule: run the vendor's uninstaller first

Always, and before touching anything else. Only the containing app can submit a deactivation request for its own extension. Only the app that saved the filter configuration can remove it from Network Extension preferences. Only the vendor's tool knows which of its components will reinstall the others if stopped out of sequence. No third-party uninstaller can acquire those handles, so a remnant scanner, Mole included, is for what is left after the vendor tool has run, never a substitute for it.

If you already dragged the app to the Trash, put it back with File > Put Back, launch it, and use its own uninstaller. The sections below say where each vendor keeps it.

Where each vendor keeps its uninstaller

Every link below points at the vendor's own support site, which is where the current steps live. Support pages move, so follow the page rather than this summary if the two disagree.

McAfee

The uninstaller is already on the Mac, in Applications, named after the product you bought, so a Total Protection install and a LiveSafe install do not use the same one. McAfee's article has you sign in as an administrator, quit every McAfee app, then open Go > Applications and double-click that uninstaller. Two of its steps are the reason to read it rather than improvise: it tells you to click Allow when macOS prompts about a system extension, and it ends with a restart as a numbered step rather than a suggestion. A dead Dock icon can survive the removal and has to be dragged off by hand.

Norton

Also a separate uninstaller app already in Applications. Norton's uninstall page walks through Go > Applications, then double-click Norton Uninstaller, then "type your administrator account password, and then click Install Helper", then the password again, then Finish. The helper step is how the uninstaller gets the privileges to unwind its own system-level components.

Avast

An in-app uninstaller, on a page that opens by ruling out the obvious alternative: "Moving Avast Security to the Trash or using Clean My Mac does not fully uninstall the application." The documented path is Avast Security > Uninstall Avast Security in the menu bar, Continue, then your Mac startup password and Install Helper. The same uninstaller also sits in Applications as Avast Security Uninstaller, for when the app will not open.

Bitdefender

A dedicated uninstaller binary rather than a drag. The uninstall page has you open the Bitdefender folder, double-click Bitdefender Uninstaller, tick the product, click Uninstall, and enter an administrator name and password. The same pass offers to remove Bitdefender VPN, worth accepting if you are not keeping it, since that component registers a network extension of its own.

Malwarebytes

An in-app menu item. The uninstall article routes you through Help > Uninstall Malwarebytes in the menu bar, a confirmation prompt, and your Mac password. Unusually for this category, the same page also accepts removal through Finder, which is a vendor statement about its own footprint. Older support.malwarebytes.com uninstall articles now redirect; use the help.malwarebytes.com page.

Sophos

Two products, two answers. Sophos Home, the consumer product, uses a separate Remove Sophos Home app launched from Spotlight. The page is blunt about the alternative: "DO NOT drag Sophos Home to the Trash as this will not uninstall the program." It installs a helper, asks for your password, and needs a restart. The same page carries an optional section for removing Sophos system extensions afterwards, and that procedure brackets systemextensionsctl uninstall between disabling and re-enabling System Integrity Protection. That is the clearest statement of where the boundary sits: even a vendor's own uninstaller does not always take its extensions with it. Those steps are optional, exactly as the vendor labels them, and SIP is worth leaving on.

Sophos Endpoint, the managed product, uses Remove Sophos Endpoint from Launchpad, but the documentation gates it: "If tamper protection is turned on, you need to turn it off before you can uninstall Sophos Endpoint." That needs a Sophos Central administrator or the per-device password held in that console, so on a work Mac it is not a user-side operation.

Kaspersky

In-app, through the support panel. The uninstall page walks through Help > Support, Uninstall, Uninstall again, then administrator credentials, and warns that the Chrome and Firefox extensions survive the app. Kaspersky also publishes a separate removal tool, kavremover-mac, for when the in-app path fails. Both pages carry 2024 dates, so confirm against your version.

If the Mac is managed, the answer is your IT team

Before spending an evening on this, check whether the decision is yours at all:

profiles status -type enrollment
profiles list

The first prints DEP and MDM enrollment state without administrator rights, the second lists configuration profiles installed for your user, and the same information appears under System Settings > General > Device Management. Apple's Device Management guide is plain about what follows: "Some profiles can only be removed by a system administrator of your Mac. If you can't remove a profile, your Mac may be a managed computer."

On a managed Mac the security software is a payload of that management. Remove it locally and the profile reinstalls it. Try to disable tamper protection locally and you cannot, because the password lives in a console you do not have. Ask IT to unassign it.

Verifying the removal

This is where a half-removal gets caught while it is still cheap. Do it after the vendor uninstaller has finished and the Mac has restarted, because several of these checks only tell the truth after a boot.

1. System extensions.

systemextensionsctl list

On a Mac with nothing installed, the output is a single line reading 0 extension(s). Otherwise each row names the team identifier, the extension's bundle identifier, its version, and a bracketed state. Anything still carrying the removed vendor's identifier means the deactivation did not complete. The tool does offer systemextensionsctl uninstall <teamID> <bundleID>, and some vendors document it for exactly this case, but reach for it only when the vendor's page tells you to.

2. launchd registrations. Look for the vendor's labels in all three locations, then ask launchd what is actually loaded:

ls -la /Library/LaunchDaemons /Library/LaunchAgents ~/Library/LaunchAgents
launchctl list | grep -i vendorname
sudo launchctl list | grep -i vendorname

The two launchctl list calls answer different questions: the first covers your login session, the second the system domain where root daemons live. A leftover plist with no matching loaded job is stale, a loaded job with no plist is a Mac that needs a reboot, and a job in both is software still running. Mole shows the same three locations as one list, which is the next section.

3. Network filters. A registered content filter appears in System Settings > Network as a Filters entry, so no entry means nothing is enrolled. One still listed after the app is gone is what is breaking your connection.

4. Login items and extensions. Open System Settings > General > Login Items & Extensions and read both the login list and the background items below it. Vendor components frequently outlive the app here.

5. Running processes. In Activity Monitor, search the vendor name and switch to All Processes from the View menu so root-owned daemons are included. An empty result after a restart is the confirmation you want.

6. Receipts. pkgutil --pkgs | grep -i vendorname names what the installer wrote, which gives you the paths worth reviewing under ~/Library/Application Support once the active components are gone.

If the first three checks are clean, the product is off the machine and everything left is disk space rather than behavior.

What Mole does here, and what it refuses to do

An uninstall review screen with an app expanded to show its bundle plus leftover items in ~/Library/Application Support and ~/Library/HTTPStorages, each with a size and a checkbox, and a Remove button at the bottom.
Every item an uninstall would touch, listed with its path and size, before anything moves. Low-confidence rows arrive unchecked, so the default action is always the smaller one.

Mole's Software tab holds the app inventory and the startup items on one screen, so the launch agents, launch daemons, and login items a product registered are visible next to the app that registered them, each with its real path.

For leftovers, Mole matches on bundle identity rather than name, and the system-level paths it knows are the ones above: /Library/LaunchDaemons/<bundle-id>.plist, /Library/LaunchAgents/<bundle-id>.plist, /Library/PrivilegedHelperTools/<bundle-id>, and the receipts under /private/var/db/receipts. Every system-level match is review-confidence, meaning it arrives unchecked: you opt in to each path after reading it, rather than opting out of a pre-ticked list. Removals go to the Trash, so a mistake is a drag back out, skipped and failed items are reported, and everything runs locally.

Two refusals matter more than any of that. Mole scans /Library/SystemExtensions for extensions owned by the app being removed, and when it finds one it raises an advisory naming that extension and saying it may remain after the app is gone. It does not attempt the deactivation, because it cannot: that request has to come from the owning app. And for vendors whose products are locked, managed, or destructive to remove piecemeal, including ESET, CrowdStrike, SentinelOne, Jamf, Palo Alto GlobalProtect, and Cisco Secure Client, Mole declines to uninstall them at all and points at the vendor's official uninstaller.

The boundary is what makes the rest of this page trustworthy, so it goes unhedged: Mole is not malware response, not a backup, and not a substitute for a vendor uninstaller on software shipping drivers, VPN components, or system extensions. For antivirus, Mole's job starts after the vendor's uninstaller has finished. In a terminal, the free and open source Mole CLI covers the same review with mo uninstall, and every destructive command takes --dry-run so you can read the path list first.

FAQ

My internet stopped working after I deleted my antivirus. What do I do?

Almost certainly a network filter configuration that outlived the app. It lives in the Network Extension preferences, which the framework manages independently of the bundle, so deleting the app leaves an enabled filter pointing at a provider that is no longer there. Check System Settings > Network for a Filters entry and systemextensionsctl list for a surviving extension. The fix is to reinstall the vendor's product and run its own uninstaller. Reinstalling software you are trying to remove feels wrong and is still the shortest path.

Can I just delete the plists in /Library/LaunchDaemons?

Not as a first move, and rarely as a last one. A plist there is a registration with launchd, so removing the file while the job is loaded leaves the job running until the next reboot with nothing on disk to explain it. Once the vendor's uninstaller has run, the Mac has restarted, and sudo launchctl list shows no matching loaded job, a stale plist is inert leftover. Never remove one belonging to software still installed.

The vendor's uninstaller asks for my password and then fails. What now?

Check three things. Is the Mac managed, in which case tamper protection or a profile is blocking removal and the answer is IT. Is the product still running, since some uninstallers cannot finish while their own daemon holds files open, so restart and retry. And is the uninstaller current, since some vendors publish a standalone removal tool separate from the in-app path. If all three are clean, vendor support is the next stop.

Do I need to restart before checking whether it is gone?

Yes. Extension teardown and launchd deregistration both complete across a boot, so a check run immediately after the uninstaller finishes can show leftovers already scheduled to disappear, and can equally hide a daemon that will come back.