`sysextd` rejects new `NEFilterDataProvider` activation with "no policy" on macOS 26 — despite valid Developer ID + notarization

Had Claude analyze the sysdiagnose report. Here are the findings:

Main observation: sysdiagnose analysis reveals sysextd never consults syspolicyd during activation

$ sudo sysdiagnose -f ~/Desktop/
This tool generates files that allow Apple to investigate issues with your
computer and help improve Apple products. The files might contain personal
information found on your device or associated with your Apple Account(s),
including but not limited to your name, serial numbers of your device,
your device name, your attached peripheral devices, your user name, your
email address and email settings, file paths, file names, Siri suggestions,
your computer's IP addresses, network connection information, and profiles
installed to your device.

This information is used by Apple in accordance with its privacy policy
(www.apple.com/privacy) and is not shared with any other company. By using
this tool and sending the results to Apple, you consent to Apple using the
contents of these files to improve Apple products.

Press 'Enter' to continue. Ctrl+\ to cancel.

Progress:
[|||||||||||||||||||||||||||||||||||||||100%|||||||||||||||||||||||||||||||||||]

Output available at '~/Desktop/sysdiagnose_2026.02.26_12-50-09-0800_macOS_Mac_25D125.tar.gz'.

The complete timeline (Feb 26, 12:49 PST):

Three things stand out:

1. syspolicyd is never consulted during extension activation. There are zero syspolicyd log entries between 12:49:14 and 12:49:15. The syspolicyd scan at 12:49:00 was the Gatekeeper first-run assessment on app launch — not the extension activation. Gatekeeper gave us result 3 (same as Zoom on this machine), so it's happy with us.

2. No user approval dialog is triggered. Zero entries from UserNotificationCenter, System Settings, or any UI prompting process. On a non-MDM machine with empty extensionPolicies, sysextd should present the "allow in System Settings" dialog. Instead it goes straight to rejection.

3. All signature verification passes. Both sysextd and trustd complete SecKeyVerifySignature and SecTrustEvaluateIfNecessary without error for both the host app and the extension. CodeSigningHelper is consulted twice and completes normally.

The failure appears to be in sysextd's internal policy lookup: it checks for an MDM/configuration profile policy (none found — extensionPolicies is empty), then fails to fall through to the user approval flow. The 1ms gap between CodeSigningHelper completing (12:49:14.601) and the "no policy" decision (12:49:14.602) suggests a simple boolean check, not a failed network call or timeout.

For comparison, Tailscale's NE on this machine (activated pre-Tahoe) only shows list/cdhash queries — never an activation flow — confirming it's grandfathered in the sysext DB as activated_enabled.

The no policy, cannot allow apps outside /Applications log entry is a red herring. It’s being emitted by the code that determines the current activation policy. The log entry indicates that there is no policy, and thus the default policy applies, which means that the container app must be in the Applications folder.

Notably, the code that logs this is a function that isn’t passed any information about your app, and thus it’s literally impossible for it to change behaviour based on whether your app is or isn’t in the Applications folder. This is normal.

The next log entry, client connection invalidated, is more of a concern. It suggests that sysextd was using XPC to talk to some helper service and that helper service went away. I’ve seen issues like that before, where the structure of your sysex causes a helper service to crash (well, trap).

See this thread, starting at this post, but also see this thread. And also check for any NE-related crash reports.

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

Thanks for responding, Quinn! Further analysis by Claude based on your inputs.

I ran sudo sysdiagnose immediately after the failure and analyzed the system_logs.logarchive. The findings suggest our situation may be different from the threads you linked.

No crash reports and no nesessionmanager involvement:

• Zero crash reports for sysextd, nesessionmanager, or CodeSigningHelper (checked both /Library/Logs/DiagnosticReports/ and the sysdiagnose archive)
• Zero connection to com.apple.nesessionmanager.system-extensions interrupted messages
• nesessionmanager has zero log entries during the activation attempt window (12:49:14–12:49:15)

The activation never reaches "staging" or "validating by category":

In thread 776759, the successful flow progresses:

activation request → realize extension → advancing state from realizing to staging → import to staging → category validation by nesessionmanager

Our flow stops before staging:

12:49:14.598  client activation request for dev.indrasvat.chakshu.filter

12:49:14.598  attempting to realize extension with identifier dev.indrasvat.chakshu.filter

              [SecKeyVerifySignature × 2, SecTrustEvaluateIfNecessary × 2 — all pass]

12:49:14.601  com.apple.CodeSigningHelper — connected and completed normally

12:49:14.602  no policy, cannot allow apps outside /Applications

12:49:14.604  client connection (pid 61491) invalidated

There are no "advancing state from realizing to staging", "Importing content", or "Container path" messages. The rejection happens in the realize phase, 1ms after CodeSigningHelper returns.

About the "client connection invalidated":

From the sysdiagnose, the "client connection invalidated" at 12:49:14.604 is sysextd tearing down the XPC connection back to our host app (pid 61491 = Chakshu) after the rejection — not a helper service crashing. The CodeSigningHelper connections at 12:49:14.594 and 12:49:14.601 both show normal completion (invalidated after the last release of the connection object), not crashes.

What nesessionmanager DOES show (but much later):

nesessionmanager has a Chakshu filter session from NEFilterManager.saveToPreferences():

NESMFilterSession[Chakshu Network Filter:30B6820D-...]: plugin NEFilterPlugin(dev.indrasvat.chakshu[content-filter][inactive])

But this is the NE configuration, not the sysex activation. At 12:50:27 (over a minute after rejection), this session is disposed with "Plugin was disabled" — which makes sense as cleanup after the failed activation.

Summary:

It appears that sysextd is rejecting during the realize phase itself, before it ever reaches category validation or contacts nesessionmanager. The "no policy" default policy check passes (our app is in /Applications), but the flow doesn't continue to staging. Something between CodeSigningHelper returning and the staging step is failing silently.

The sysdiagnose archive (sysdiagnose_2026.02.26_12-50-09-0800) is available — happy to attach it or share any specific sections.

Follow-up: Notarization ticket database analysis

I ran diagnostic queries against the three SystemPolicyConfiguration databases (ExecPolicy, SystemPolicy, Tickets) comparing my extension against a working Tailscale NE on the same machine. Here's what I found.

Tickets database

The Tickets database has two tables: tickets (direct entries) and hashes (component CDHashes linked to a parent ticket).

After xcrun stapler staple Chakshu.app:

For comparison, Tailscale's extension CDHash has a direct entry in tickets (id=639).

ExecPolicy policy_scan_cache

policy_match=4 appears to be the "Notarized Developer ID" assessment. policy_match=9 is the default/legacy assessment — the most common value in the table (350 of 910 entries). My extension consistently gets the legacy assessment.

SystemPolicy object_state

The object_state table confirms both my app and Tailscale are recognized as "Notarized Developer ID" (authority 11) at the app bundle level. The problem is specifically at the extension level.

Hypothesis

stapler staple writes the top-level app CDHash as a direct entry in tickets but only records nested component CDHashes (including the system extension) in the hashes table. If sysextd's policy evaluation looks up the extension's CDHash only in tickets and not hashes, it would fail to find the notarization ticket and fall back to the legacy Developer ID assessment — which would explain the "no policy" rejection.

Tailscale's extension works because it has a direct tickets entry, likely created when it was first activated on a pre-Tahoe macOS version.