I had a similar error, for me using sudo systemextensionsctl reset resolved the problem.

Thanks for the feedback, Matt. I'll get in touch with support and update this thread when I know more.

Matt, Thanks for the response. For example, caching flow meta information and then later in one of the provider's lifecycle methods match and revoke the flow? Once we have given an allow verdict, we don't receive further lifecycle callbacks. The only way I can see to do that would be instead of returning an allow verdict we would need to return a NEFilterNewFlowVerdict.filterDataVerdict(withFilterInbound, filterOutbound) to allow a little data through at a time and decide in handleInboundData() or handleOutboundData() to block or repeat letting a small amount through. I worry this could be a lot more overhead and add unwanted CPU load. A secondary question, which might help with "housekeeping" of flows, if we provide a block verdict to a flow is that flow guaranteed to be closed? We could drop it from our cache if we're sure it won't useable again. Thanks, Dave

Thanks for the clarification, Matt. If our app is installed or updated without a user login active, ie via MDM like JAMF, how should we ensure the Container App is run on login so that the system extension activation or update (ie .replace) is performed? I'm trying to use a Helper application installed using SMLoginItemSetEnabled but it's not starting the App. However, will that even work from a MDM install?

It depends on where the dropVerdict comes in at. For example, if it comes in at handleNewFlow, then yes, the flow will be dropped before opened. If it comes in during the connection lifecycle methods, for example handleInboundDataFromFlow and handleOutboundDataFromFlow then the connection will be opened and then dropped. Would this also be true of a call to updateFlow:withVerdict:forDirection: outside of the normal lifecycle methods?

Hi Matt, Thanks for the clarification. Our and our customers' IT departments typically want to be be able to deploy or remove macOS apps via an MDM (JAMF in our case). We distribute an MDM profile to pre-authorize system extension and content filter installation (and removable system extensions on Monterey). The requirement/recommendation to need a logged in user does hamper management of apps via MDM. Is there any intention or roadmap to support deployment or removal of system extensions with suitable MDM profile but without requiring a user logged in? Regards, David

Raised a suggestion via Feedback Assistant, FB10491553 Dave