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): Time Process Event 12:49:00.624 syspolicyd GK performScan — team: R65679C4F3 12:49:00.821 syspolicyd GK evaluateScanResult: 3 — id: dev.indrasvat.chakshu (scan passed) 12:49:01.184 syspolicyd XProtect: "Forwarding detection succeeded!" 12:49:14.583 Chakshu Connects to com.apple.sysextd via XPC 12:49:14.587–592 sysextd Verifies host app signing — SecKeyVerifySignature × 2, SecTrustEvaluateIfNecessary × 2 (pass) 12:49:14.594 sysextd → CodeSigningHelper Host app check 12:49:14.598 sysextd "attempting to realize extension with identifier dev.indrasvat.chakshu.filter" 12:49:14.598–601 sysextd Verifies extension signing — same checks (pass) 12:49:14.601 sysextd → CodeSigningHelper Extension check 12:49:14.602 sysextd "no policy, cannot allow apps outside /Applications" 12:49:14.605 Chakshu Receives OSSystemExtensionError code 4 Three things stand out: 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. 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. 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.

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: CDHash tickets (direct) hashes (linked) Host app 02d771fe... Yes (id=940) Yes → ticket 940 Extension 658144fa... No Yes → ticket 940 For comparison, Tailscale's extension CDHash has a direct entry in tickets (id=639). ExecPolicy policy_scan_cache Binary policy_match flags Tailscale extension 4 8704 My host app 4 8704 My extension 9 64 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.