I don't have logs, only a memgraph, so I can't say whether there were 2 starts logged. The 2 instances are referenced by a collection object (owned by a different class instance). The data filter instance adds itself to the collection from the startFilterWithCompletionHandler: method and removed itself from the collection from the stopFilterWithReason: method. So the most probable hypothesis is that the stopFilterWithReason: was not called. Which would be more a bug in the NetworkExtension framework. I haven't been able to reproduce this case so far (like by disabling/enabling the Network filter from the System Settings).

Feedback ID: 18731867

It can be reproduced in macOS 26 beta 1 and beta 2.

It looks like that the issue is not reproducible in the 15.6 RC.

I don't think the problem is coming from the macOS instance itself as the problem does not occur when the extension is updated using an installation package. The problem only happens when replacing the system extension and its wrapper .app using basic NSFileManager APIs. I diffed the 2 cases and there are no differences. Same files, same contents. And anyway spctl and codesign are happy. I tried different macOS versions in VMs (14, 15). Same result. What I'm also observing is that after updating the system extension using an installation package, just using the NSFileManager APIs is going to work fine when reverting to any version that has been previous installed via an installation package or updating to version that has been previously updated via an installation package.