the app is gone. its system extension is still there.

find out what is loaded: systemextensionsctl list and kmutil

three different things get called «system extension», and each is removed a different way, so the first minute is spent finding out which one you have. open Terminal and run systemextensionsctl list. the output is grouped by category — network, endpoint security, driver, camera — and each group is headed by the exact place in System Settings that manages it. under it, one line per extension: whether it is enabled, whether it is active, the developer's team id, the bundle id with its version, and a state in square brackets. [activated enabled] is running. [terminated waiting to uninstall on reboot] means the removal already happened and a restart finishes it.

if the list is empty and something is still there, it is a kernel extension: kmutil showloaded --list-only, with grep -v com.apple to hide Apple's own, shows what is in the kernel right now, and ls /Library/Extensions shows what is installed whether or not it is loaded. kextstat still works, but it now only wraps that kmutil call.

which kind is it

• a system extension: shows up in systemextensionsctl list, lives in /Library/SystemExtensions under a random id, is owned by root. vpn clients, firewalls, antivirus, virtual cameras, audio drivers written after 2019.
• a kernel extension, or kext: a .kext folder in /Library/Extensions, listed by kmutil. older drivers — disk controllers, ntfs, audio interfaces, anything that says «legacy system extension» in an alert.
• neither: a launch daemon or a helper in /Library/LaunchDaemons or /Library/PrivilegedHelperTools that behaves like a driver but is an ordinary program. that one is a leftover, and leftovers have their own page.

Apple's own split is the same — extensions on one side, and «legacy system extensions» on the other, which it defines as «kernel extensions, or kexts»: if you get an alert about a system extension on Mac

if what refuses to go is the app itself rather than its extension, that is a different set of five reasons: delete an app that will not delete

remove a system extension the way macOS wants: through the app that owns it

macOS ties an extension to the app bundle that brought it. deleting that bundle is the designed removal. if the app is still installed, this is the whole procedure:

1. quit the app and its menu bar helper if it has one.
2. drag the app from /Applications to the Trash in the Finder — the Finder specifically, because the dialog that follows is the Finder's. it names the app and says its system extension will be removed. accept it.
3. run systemextensionsctl list again. the line should be gone, or read [terminated waiting to uninstall on reboot]. restart, and it is gone.

the app was already deleted and the extension stayed

this is the case most of the threads are about, and the fix sounds backwards: install the app again, then delete it from /Applications the way above. the dialog fires on the second deletion, and the extension goes with it. put the bundle back and the system has something to remove again. it is where the Apple developer forums end up too, usually after a third-party uninstaller took the app without triggering the dialog.

before reinstalling, try the two shorter routes. systemextensionsctl gc — garbage collect — removes extensions whose owner is no longer anywhere; when it finds none it says so and exits, so it costs nothing to run first. and System Settings → General → Login Items & Extensions has an Extensions list at the bottom: in the By App view the ⓘ next to an entry opens a sheet with one switch per extension, which turns it off without removing it. Objective Development, who ship a network extension, describe a Delete Extension item in the By Category view under Network Extensions — that is the removal, and the reason it exists is that on macOS 26 the Finder dialog sometimes promises a removal that never happens.

their write-up of that failure is the clearest thing published on it — «the extension remains registered in the system» — and it has the exact click path: Objective Development: deletion impossible, again

the rest of what the app left — caches, preferences, launch agents, the receipt that keeps macOS believing a version is installed — is not touched by any of this, and lives here: uninstall an app with its leftovers

uninstall a kext: /Library/Extensions, kmutil and a restart

a kernel extension is older and simpler: it is a folder, and the folder is the extension. the vendor's own uninstaller is the right first move — Apple says to look for one in the app's folder, and for drivers it is right, because the uninstaller knows the kext's name and the daemon that goes with it. without one:

1. find it: ls /Library/Extensions. the name usually gives the vendor away.
2. unload it if it is loaded: sudo kmutil unload -b the.bundle.identifier — the id is in kmutil showloaded, or in the Info.plist inside the folder. an extension in use will refuse; that is fine, the next step still works.
3. move the folder out: sudo rm -r /Library/Extensions/Name.kext, or drag it to the Trash and authenticate. it is owned by root, so it asks either way.
4. restart. the kernel collection is rebuilt at boot, and the kext is no longer in it.

on Apple silicon the kext may not be loadable at all

a Mac with Apple silicon refuses third-party kexts unless someone went into Recovery, set the startup security to Reduced Security and ticked «allow user management of kernel extensions from identified developers». if that was never done, the kext you found in /Library/Extensions was never loaded — it is a folder taking up space, and removing it changes nothing but the alerts. if it was done, the setting stays after the kext is gone, and putting it back to Full Security is a separate visit to Recovery.

the setting, where it lives and what it costs are in Apple's page on the startup disk security policy: change security settings on the startup disk of a Mac with Apple silicon

it is also why the App Store build of a driver-heavy app never brings a kext: the sandbox forbids loading one, which is one of the real differences between the two builds: the App Store version versus the one from the site

when the system extension cannot be removed: Recovery, SIP and systemextensionsctl uninstall

some extensions survive all of the above: the owner app is gone and cannot be reinstalled, gc reports nothing, the settings pane has no delete for that category, and the line in systemextensionsctl list stays [activated enabled]. antivirus and endpoint security agents from a former employer are the usual ones. for these there is one command, and it does not run on a normal Mac.

systemextensionsctl uninstall takes the team id and the bundle id from the list output. run it with SIP on and it answers: «At this time, this tool cannot be used if System Integrity Protection is enabled. This limitation will be removed in the near future.» that sentence has been the answer since 2020 — Rich Trouton quoted it word for word then, and macOS 26.6 still prints it. so the procedure is the long one:

1. boot into Recovery: on Apple silicon hold the power button until Options appears; on Intel hold ⌘R.
2. open Utilities → Terminal and run csrutil disable. on Apple silicon this switches the startup policy to Reduced Security for you and asks for an administrator password.
3. restart normally, open Terminal, and run sudo systemextensionsctl uninstall TEAMID com.vendor.bundle.id with the two values from the list. check the list again.
4. boot into Recovery once more and run csrutil enable. do not skip this; a Mac with SIP off is not the Mac you started with.

the same dead end, from the other side — a user with a firewall extension from an uninstalled antivirus, told he does not have permission, and the thread ending at exactly this procedure: Apple Community: can't delete a system extension

if the alternative you have read is sudo rm -rf on /Library/SystemExtensions: the folder belongs to root and the extension is still registered in the database next to it, so at best you get a permission error and at worst a list entry that points at nothing. the uninstall command is what edits that database, which is why it is the one that needs SIP off.

what hop does here, and what it does not

hop does not remove system extensions or kexts. nothing that is not the system does — a tool claiming to is either turning SIP off behind a password prompt or deleting the folder and leaving the registration. what the uninstall module does is the other half of the job: it removes the app that owns the extension together with what it left in about thirty places, and when macOS refuses to hand something over it names the item and the reason instead of reporting success.

so the order is: first take the extension out through the system — the Finder deletion, the settings pane, gc — while the owner app is still installed and the dialog can fire. then use the module for the leftovers: the launch daemon that kept the extension company, the preferences, the receipt in /var/db/receipts. an app already in the Trash is still recognised, so the leftovers can still be matched to it after the drag.

what the module sees and what it moves to the Trash, without the adjectives: app uninstaller

and why the folder that stays behind is usually much smaller than the number the cleaners quote: what the space a cleaner finds is made of

when the extension still will not go away

• the Finder dialog appeared, you accepted, and the list still shows the extension. known on macOS 26: the dialog promises what does not happen. use the Delete Extension item in Login Items & Extensions → By Category, or reinstall and delete once more.
• the state reads [terminated waiting to uninstall on reboot] and does not change. it is waiting for exactly that. restart — a log out is not enough here.
• System Settings shows the extension greyed out and says it is managed. a configuration profile from an employer owns it; check General → Device Management. no local step removes it while the profile is installed.
• the vpn, firewall or antivirus is gone but the network is broken. a network extension that stayed active without its app keeps filtering traffic it can no longer hand to anyone. it is the first thing to check when a vpn says connected and nothing loads.
• the kext is gone from /Library/Extensions but kmutil still lists it. the kernel collection is rebuilt at boot; if it is still there after a restart, run sudo kmutil clear-staging and restart again.

the network case has its own page, because it is what most people are actually chasing when they land on this one: fix a vpn that says connected with no internet

frequently asked questions

how do i see which system extensions are installed on my Mac?

run systemextensionsctl list in Terminal. it groups them by category, names the settings pane for each, and gives the team id, bundle id and state per extension. for kernel extensions use kmutil showloaded --list-only for what is loaded and ls /Library/Extensions for what is installed.

does deleting the app remove its system extension?

that is the designed way, yes: drag the app from /Applications to the Trash in the Finder and accept the dialog. it fails on some macOS 26 builds and it does not fire when a third-party tool removes the app, which is how extensions end up orphaned.

the app is already gone. how do i remove the extension it left?

try systemextensionsctl gc first; it removes extensions whose owner no longer exists. if that reports nothing, reinstall the app and delete it again from the Finder so the removal dialog can fire. the last resort is systemextensionsctl uninstall with SIP turned off in Recovery.

why does systemextensionsctl uninstall say it cannot be used?

because System Integrity Protection is on, and the command refuses to run under it — the message says the limitation will be removed «in the near future», and has said so since 2020. it runs after csrutil disable from Recovery, and SIP should go back on straight after.

can i just delete the folder in /Library/SystemExtensions?

it is owned by root, so a plain delete is refused, and deleting it as root leaves the registration in the database next to it pointing at nothing. the uninstall command is what removes the registration; the folder goes with it.

can an uninstaller app remove a system extension or kext?

no, and that includes hop. the system only lets its own mechanisms deactivate an extension — the Finder deletion, the settings pane, systemextensionsctl. what an uninstaller can do is remove the owner app and its leftovers, and tell you what it could not remove and why.

the tool behind this

done with uninstall apps

other things people do

• the app is gone. its eighteen folders are not.app uninstaller
• the app will not go in the trashapp uninstaller
• system data: 180 gb, contents unspecifiedapp uninstaller