I checked KayleeSC's suggestion and found that all affected systems I tested are using a non-501 user ID. On the machine where I originally reproduced the issue, URL filtering works correctly for a UID 501 user.

ar_ivanov and I discovered this issue independently. I reproduced the issue on macOS 26.4.1 and continued to observe the same behavior after upgrading that machine to 26.5.1. The issue is also reproducible on a second machine running 26.5.1 and on another machine running 26.3. All tested systems had SIP disabled and systemextensionsctl developer mode enabled. I also re-enabled SIP and checked the issue again after several subsequent reboots. The issue persisted. I repeated the permissions change for /private/var/db/urlPrefilter/ described by ar_ivanov and observed the same behavior. The issue remained reproducible.

I’m seeing a similar issue on macOS 26.3.1. It doesn’t reproduce every time, but it tends to happen when calling SFContentBlockerManager.reloadContentBlocker twice with a ~2s delay: first reload loads large JSON (~9–11 MB) second reload updates rules to almost empty (~100 bytes) Both calls return success and files on disk look correct. But after the second reload Safari sometimes doesn’t call beginRequest for some blockers, and they keep using old rules. In my logs, these are the same blockers that loaded large JSON in the first reload. If I increase the delay between reloads, the issue mostly disappears.