sysextd: "no policy, cannot allow apps outside /Applications" - NEFilterDataProvider system extension on macOS 26

Update: After inspecting all provisioning profiles on our system, we found that:

Profiles generated for development and Developer ID distribution contain content-filter-provider Profiles generated via Direct Distribution contain only packet-tunnel-provider-systemextension and app-proxy-provider-systemextension No profile contains content-filter-provider-systemextension

When we set content-filter-provider-systemextension in the entitlements file (matching Little Snitch's configuration), Xcode rejects all available profiles with a mismatch error. This means the Developer Portal does not appear to generate provisioning profiles with content-filter-provider-systemextension for content filter system extensions. Is this a portal issue, or is there a different provisioning mechanism required?

It sounds like you’re using Developer ID signing for day-to-day development. That’s a mistake on multiple levels. I talk about this in general in The Care and Feeding of Developer ID, but there are extra issues with system extensions, where system policy requires that Developer ID signed sysexen be notarised.

So my advice in this case.

• Use Apple Development code signing for day-to-day development.
• Use Developer ID for pre-release testing and distribution.

There are a couple of key benefits with this approach:

• It lets you build and debug without enabling development mode, which is a big win IMO.
• Xcode’s automatic code signing works well with Apple Development signing.

Even if you’re not using Xcode, you can create a small test project in Xcode, get it working, and then follow the same path it took. See Debugging a Network Extension Provider for specific advice on how to bring up a provider in Xcode.

One thing that Xcode doesn’t handle is the -systemextension suffix )-: To learn more about that, read Exporting a Developer ID Network Extension.

Finally, you wrote:

On macOS 26 beta (25E241)

If possible, try to avoid developing on a beta release. Rather, developer with production versions of macOS and Xcode, and then test what you’ve built on both production releases and on our beta seeds.

I think that’ll be enough to get you up and running, but please write back here if you hit any snags.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Adding a data point since our config is a step further than the OP's and still fails — might narrow this down.

Setup: NEFilterDataProvider system extension, Developer ID Application signed, fully notarized (Accepted) and stapled, running on macOS 27.0 "Golden Gate" (26A428) — the public GM release, not a beta.

Unlike the OP, our entitlements already use the -systemextension suffix on both sides:

• Container app: com.apple.developer.networking.networkextension = [content-filter-provider-systemextension], com.apple.developer.system-extension.install = true
• Extension: com.apple.developer.networking.networkextension = [content-filter-provider-systemextension], app-sandbox = true, application-groups set

And unlike the OP's finding, our Developer Portal-issued profiles DO contain content-filter-provider-systemextension — confirmed by decoding the embedded provisioning profile directly (security cms -D) on both the container and the extension. So in our case the portal is generating the right entitlement value; that's not the blocker.

We still get the exact same rejection: sysextd: no policy, cannot allow apps outside /Applications

...immediately after sysextd validates and dumps our app's own entitlements (confirmed correct) via the unified log. The app is genuinely at /Applications/SecureMac.app, no quarantine xattr, no translocation. /Library/SystemExtensions/db.plist shows zero prior record for our extension identifier — so it's not a stale/poisoned cache from earlier testing either. A full reboot didn't change anything.

The one thing that does correlate: we found a crash report on this same Mac from a completely unrelated, already-shipping Developer ID product (Little Snitch) showing "developerMode" : 1 in its own crash metadata from when its system extension was actively working. Our current system state has developerMode: false (SIP enabled, the normal/correct posture). That strongly suggests activation is effectively gated behind Developer Mode (and therefore SIP disabled) even for a fully correct, notarized, Developer ID + -systemextension-suffixed configuration — not just for ad-hoc/local development builds.

Given that: is there a supported path for a Developer ID + notarized NEFilterDataProvider extension to activate for an ordinary end user — SIP enabled, Developer Mode never touched — at all on 27.0? If Developer Mode really is required, that's a hard blocker for shipping this to customers, not just a development inconvenience, and I want to make sure we're not missing a step before concluding that.

Happy to share full log excerpts / entitlement dumps if useful.

So are you seeing this issue on just one Mac? Or across a wide range of them?

My standard test for this stuff is pretty much what I outline in Testing a Notarised Product, that is, use a VM to test and then retest on a (virtual) Mac that’s never seen my product before. If you do that, do you see the problem?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"