I’m seeing very similar behavior (macOS 27), and a controlled test revealed a potentially useful detail about the Local Network settings UI. Chrome cannot reach a local HTTP service and reports ERR_ADDRESS_UNREACHABLE. Safari and a direct command-line request succeed on the same Mac. Chrome’s code signature verification also passes. All Chrome entries in System Settings appear enabled. However, inspecting the persisted NetworkExtension configuration shows that the rule for the currently installed Chrome application still has: DenyMulticast = true MulticastPreferenceSet = true There are also multiple rules referencing code_sign_clone temporary copies whose executables no longer exist. During a controlled test, I switched one Chrome entry off, waited several seconds, and switched it back on while monitoring only Chrome-related configuration changes: The other Chrome switches visibly changed together in System Settings. Only one orphaned temporary-copy rule changed in the persisted configuration. The rule for the currently installed Chrome application remained denied throughout. The system continued logging: Local network denied by preference for Google Chrome (com.google.Chrome) This suggests a mismatch between the state displayed for the Chrome entries and the particular path-based rule actually being updated. It may help explain why toggling apparently enabled permissions has no effect. I also observed policy reinstall retries through retry 5, although I haven’t established that the loop continues indefinitely. Fully restarting Chrome, cycling the permissions, and renaming the application did not resolve the issue. Is there a supported way to repair the affected application’s rule while preserving other applications’ permissions and VPN configurations? Is this UI-to-rule mismatch tracked separately from the duplicate-entry issue?