Since Sequoia (15.0), versions of macOS have shipped with a "Local Network" privacy setting that governs access to devices on your local network. It's a good idea but it could use a redesign.

When a third party app requests access to any device that shares your local network (ie. a private IP address provided by your router instead of a public IP address), it checks your Local Network permissions. If this app has never requested access to your local network before, it will pop up a dialogue asking you to approve it. So far so reasonable.

Because this alert pops up any time the networking APIs are accessed, it sometimes happens right on first launch or when you're not intuitively expecting it to. And in those cases, no, I don't want to allow blanket permission for some software to access my local network. That's a security feature that's working as intended.

From that point forward, you can't access any local devices from that app's command line or browser. And no matter how long ago you gave that initial deny, the network connection is still blacklisted.

In theory, applications can detect that they've been blocked and show a helpful error message. If TCP requests are being made through NWConnection, the connection will enter a waiting state when access is denied. localNetworkDenied indicates that the system has denied local network access.¹ Bonjour has a similar callback.

In reality, most applications don't implement this handler or are using different networking APIs that don't have access to the same state. User-facing errors end up being incredibly cryptic about what's going on.

In third party Terminals like Warp or Ghostty²:

$ ssh [email protected]
ssh: connect to host 192.168.1.60 port 22: No route to host

Or in Chrome:

These errors themselves aren't Apple's fault. Developers could implement a fallback that checks the Local Network permissions for blocks. But until they do, user experience is hurt for the worse by this new privacy setting.

Instead, I'd suggest Apple redesign these privacy settings to consider applications that don't enumerate this full universe of permission errors:

• Pop up a Control Center notification when network access is blocked. These notifications are non-blocking and give the additional context of what's being blocked. They should also be infrequent: they can be capped at once per app launch.
• Expand the NSPrivacy framework to let apps check their system permissions on bootup without having to make a proactive request to NWConnection.

Sometimes platforms can throw too much weight on the shoulders of developers. If all third party apps immediately adopted the new callbacks, this would be a non-issue. But for software that's older or just doesn't consider the changes, it's a worse experience for users. That's on the platform to fix, not just the ecosystem.