The Death of Kernel Extensions (Kexts)
For decades, if a software developer needed deep integration with the macOS operating system—such as creating an enterprise antivirus scanner, an advanced firewall, or a specialized USB device driver—they wrote a Kernel Extension (Kext). Kexts were injected directly into the macOS kernel space. While extremely powerful, they were also extremely dangerous. A single bug in a third-party Kext would cause a catastrophic kernel panic, instantly crashing the entire Mac.
Starting with macOS Catalina and strictly enforced in macOS Big Sur and later (especially on Apple Silicon), Apple aggressively deprecated Kernel Extensions. They were replaced by System Extensions.
System Extensions provide the exact same functionality (Network Extensions, Endpoint Security Extensions, and Driver Extensions) but run entirely in user space. If a System Extension crashes, it simply restarts without bringing down the operating system. However, managing the lifecycle of these deeply embedded background processes requires administrators to utilize the systemextensionsctl command.
Step 1: Listing Active System Extensions
Unlike standard applications in the /Applications folder, System Extensions embed themselves invisibly into the operating system. You cannot manage them effectively using the Activity Monitor.
To view every System Extension currently registered on the Mac, open the Terminal and run:
systemextensionsctl listThe output will display a table containing several critical pieces of information for each extension:
- TeamID: The unique alphanumeric identifier for the developer (e.g.,
EQHXZ8M8AVfor Google). - BundleID: The specific identifier for the extension (e.g.,
com.google.drivefs.fps). - State: The current lifecycle status (e.g.,
[activated enabled]).
Step 2: Understanding the Lifecycle States
A System Extension rarely installs cleanly and silently on an unmanaged Mac. Apple enforces strict user-consent policies. When you run systemextensionsctl list, you might see several different states:
[activated enabled]: The extension is perfectly healthy, running, and approved by the user (or by an MDM profile).[activated waiting for user]: The software installed the extension, but macOS is actively blocking it from running. The user must open System Settings > Privacy & Security and explicitly click the “Allow” button.[uninstalling]: The parent application has requested the removal of the extension, but macOS cannot delete it yet because a process is still actively utilizing it, or the system is awaiting a reboot.
Step 3: Uninstalling Stubborn Extensions
One of the most infuriating problems with System Extensions occurs when a user drags a third-party application (like an old VPN client) directly to the Trash instead of using its official uninstaller. The parent application is deleted, but its System Extension is permanently left orphaned and running in the background, consuming CPU and potentially causing network conflicts.
You can use systemextensionsctl to explicitly sever and delete these orphaned extensions.
You must specify the TeamID and the BundleID of the offending extension (found via the list command in Step 1).
systemextensionsctl uninstall EQHXZ8M8AV com.google.drivefs.fpsCrucial Note: As a security measure, Apple prevents you from running this uninstall command freely. You must temporarily disable System Integrity Protection (SIP) from the macOS Recovery Environment, execute the uninstall command, and then re-enable SIP.
Step 4: Bypassing User Consent with MDM
In an enterprise environment, it is unacceptable to deploy a mandatory Endpoint Detection and Response (EDR) agent (like CrowdStrike or SentinelOne) and rely on the end-user to open System Settings and click “Allow.” The machine will remain completely unprotected until they do so.
While you cannot use systemextensionsctl to bypass this locally, the output of the list command provides the exact mathematical values you need to configure an MDM Configuration Profile.
When building the MDM payload for your fleet, you use the TeamID and BundleID extracted from the terminal to create a SystemExtensions payload. This payload instructs macOS to silently auto-approve the extension the moment it touches the hard drive.
<key>AllowedSystemExtensions</key>
<dict>
<key>EQHXZ8M8AV</key>
<array>
<string>com.google.drivefs.fps</string>
</array>
</dict>When this profile is pushed via Jamf or Kandji, a subsequent systemextensionsctl list check will instantly display [activated enabled] without any user interaction.
Step 5: Resetting the Subsystem (The Nuclear Option)
Occasionally, the entire macOS System Extension database becomes corrupted. Legitimate extensions refuse to load, the System Settings pane hangs, and systemextensionsctl list returns empty or garbled output.
When standard troubleshooting fails, you can reset the entire System Extension subsystem. This will forcefully wipe the internal SQLite database and force macOS to rebuild the list from scratch.
systemextensionsctl resetWarning: This command destroys all current extension registrations. When the Mac reboots, every single piece of third-party software that relies on an extension (VPNs, Antivirus, Cloud Drives) will believe it has just been installed for the first time and will violently prompt the user for re-approval, unless an MDM profile is actively enforcing the allowlist.
Conclusion
The transition from Kernel Extensions to System Extensions massively improved the stability and security of macOS, but it introduced a complex lifecycle management problem. By utilizing the systemextensionsctl command, administrators can peer into the hidden architecture of these background daemons, identify blocked processes, orchestrate silent enterprise deployments, and forcefully excise orphaned software that traditional uninstallers leave behind.