Summary

The "Allow ... to find devices on local networks?" prompt is turned off for all private LAN addresses using two system preferences Apple documents in TN3179. They were applied on this Mac (macOS 26.6.2) on 10 October 2026. A reboot is needed before they take effect.

The problem: macOS 15 added Local Network privacy, and macOS identifies each app partly by its executable's UUID. Every macOS update and many app updates create a new identity. Apps, auto-start jobs and tools then lose LAN access until someone clicks the prompt again.

The fix tells macOS to treat the private ranges as not local. Every program can reach them without a prompt, whatever its permission state. Nothing runs as root, SIP stays on, and no system files are edited.

The command

This was run once in Terminal. sudo is required because the setting applies to the whole system.

sudo defaults write com.apple.network.local-network AllowedEthernetLocalNetworkAddresses -array 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
sudo defaults write com.apple.network.local-network AllowedWiFiLocalNetworkAddresses -array 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

Then reboot. Apple says the change has no effect until you restart.

Both keys get the same list, so the override applies whether the Mac is on Wi-Fi or wired Ethernet.

How it works

Local Network privacy doesn't go through TCC, the normal privacy database. The Network Extension framework enforces it as a packet filter deep in the network stack, with per-app rules. So tccutil, privacy profiles and TCC.db edits can't touch it, and Apple says MDM can't configure it either.

Since macOS 15.5, Apple has provided two system-wide preferences in the com.apple.network.local-network domain (stored in /Library/Preferences/com.apple.network.local-network.plist):

• AllowedEthernetLocalNetworkAddresses applies to wired Ethernet interfaces.

• AllowedWiFiLocalNetworkAddresses applies to Wi-Fi interfaces.

Each takes an array of IPv4 or IPv6 networks in CIDR form. In TN3179's words: "the system treats every address on that network as if it were not a local network address. Every program can access that address, regardless of its Local Network privilege state."

The check is about the destination address, not the app. App identity, updates and UUID changes stop mattering for traffic to these ranges. Apple intended the setting for site administrators and CI machines that can't have someone clicking prompts.

Even without the override, macOS already allows local network access for:

• Daemons started by launchd (not launchd agents)

• Any program running as root

• Command-line tools run from Terminal or over SSH, and their child processes

Verify

Check the setting is stored (no sudo needed to read it):

defaults read /Library/Preferences/com.apple.network.local-network

You should see both keys, each listing the three ranges. After the reboot, test it:

1. Open a GUI app that used to prompt and get it to reach something on the LAN, such as a NAS, printer or Home Assistant. Terminal won't work as a test, because command-line tools are already exempt.

2. No prompt and a working connection means the override is active.

3. Run the same check after the next macOS update and the next app update, since those are the cases that used to break.

If a prompt still appears, note which app and what it was doing. Bonjour-style discovery is the most likely gap (see Caveats).

Rollback

To undo everything and go back to stock macOS behaviour, delete the domain and reboot:

sudo defaults delete com.apple.network.local-network

# then reboot

After the reboot, apps go back to their own Local Network permissions, and some may prompt again.

Partial rollback. To remove just one interface's override, delete one key:

sudo defaults delete com.apple.network.local-network AllowedWiFiLocalNetworkAddresses

To change the ranges, run the original defaults write again with the new list. It replaces the old list rather than adding to it. Reboot after either change.

If the Mac is unusable. This setting only relaxes a network check, so it shouldn't affect booting. As a last resort:

1. Boot into Recovery.

2. Open Terminal from the Utilities menu.

3. Delete the file: rm "/Volumes/Macintosh HD - Data/Library/Preferences/com.apple.network.local-network.plist". Adjust the volume name if yours differs.

4. Reboot normally.

Caveats and extending

• Bonjour and mDNS discovery might still prompt. Finding AirPlay devices, printers or Sonos goes through mDNSResponder, which runs its own policy check (kDNSServiceErr_PolicyDenied), not just address matching. Next step if it does: add 224.0.0.0/4 (IPv4 multicast) and ff00::/8 (IPv6 multicast). It's not confirmed that those are honoured.

• Ranges not covered: link-local 169.254.0.0/16 (direct cable links, some IoT setup modes), IPv6 ULA fc00::/7 and IPv6 link-local fe80::/10. Add them to both arrays if a device on one of these still prompts.

• Tailscale (100.64.0.0/10) is not treated as a local network, so it needs no entry.

• Security trade-off: any process can now reach those LAN ranges without asking, including a malicious one. That's how macOS worked before version 15.

• Auto-start jobs: launchd daemons were already exempt, but launchd agents were not, which is why login-time jobs broke. The override covers agents too.

• Future macOS: macOS 27.2 adds +/- buttons to the Local Network list, and macOS 27 adds a per-app "LocalNetwork: Allow" setting for MDM-managed Macs. Neither is system-wide, so this override still applies. Re-check TN3179 after major upgrades in case Apple changes the keys.