NSURLErrorNotConnectedToInternet (-1009 / ENETDOWN) connecting to a local network host — only on macOS 27 Golden Gate Public Beta Summary

Reposting with improved readability. The content remains the same.

Summary

Our macOS app makes an URLRequest (via URLSession) to an HTTP(S) server on the local network (a device at a private IP address, e.g. 192.168.x.x). The request fails with NSURLErrorNotConnectedToInternet (-1009) whose underlying error resolves to ENETDOWN (POSIX errno 50) at the socket/connection level — i.e. the failure happens before any TLS/HTTP exchange, at connect() time.

This only reproduces on macOS 27 "Golden Gate" Public Beta. The exact same build/binary works correctly on:

• macOS 26 "Tahoe" (shipping release)
• macOS 27 "Golden Gate" Developer Beta

Based on our diagnosis, we believe the Local Network permission prompt itself is never firing for direct-IP (non-Bonjour) connections on this Public Beta build, leaving the app's Local Network TCC grant permanently stuck in an "undetermined" state — which then surfaces as ENETDOWN. This is consistent with the app not appearing at all in System Settings → Privacy & Security → Local Network, and with tccutil reset LocalNetwork failing both per-app and system-wide (there's no grant to reset in the first place). We'd like a sanity check / to know if others are seeing this, and whether there's a known workaround.

Environment

• App: com.example.Client, non-sandboxed
• Target: https://<local-ip>:<port>/api/...
• macOS versions tested: macOS 26 Tahoe — OK; macOS 27 Golden Gate Developer Beta — OK; macOS 27 Golden Gate Public Beta (build: 26A5388g) — fails
• Mac model: Mac mini
• Xcode version used to build: 27 beta 2

Error details

URLSession completion error:

Error Domain=NSURLErrorDomain Code=-1009 "..." UserInfo={
  _kCFStreamErrorCodeKey=50,
  NSUnderlyingError=0x... {
    Error Domain=kCFErrorDomainCFNetwork Code=-1009 UserInfo={
      _NSURLErrorNWPathKey=...,
      _kCFStreamErrorCodeKey=50,
      _kCFStreamErrorDomainKey=1
    }
  },
  ...
}

_kCFStreamErrorDomainKey=1 is kCFStreamErrorDomainPOSIX, and code 50 is ENETDOWN. Console log for the same request shows the failure at the connection layer, before any TLS/HTTP activity:

Connection 1: received failure notification
Connection 1: failed to connect 1:50, reason -1
Connection 1: encountered error(1:50)
Task <...>.<1> HTTP load failed, 0/0 bytes (error code: -1009 [1:50])

What we've ruled out / tried

1. Added NSLocalNetworkUsageDescription to Info.plist — no change in behavior.

2. Confirmed via codesign -d --entitlements - and plutil -p Info.plist that the built/signed app bundle actually contains the key.

3. Checked System Settings → Privacy & Security → Local Network — the app itself does not even appear in the list.

4. Tried resetting the Local Network TCC grant:

   sudo tccutil reset LocalNetwork com.example.Client

→ tccutil: Failed to reset LocalNetwork approval status for com.example.Client

Also tried a full reset for the service (no bundle id):

 sudo tccutil reset LocalNetwork

→ tccutil: Failed to reset LocalNetwork

Confirmed tccutil itself is functioning normally on this machine — resetting other services succeeds, e.g.: sudo tccutil reset Camera

→ Successfully reset Camera

So tccutil works in general, but the LocalNetwork service specifically cannot be reset, on this Public Beta build, either per-app or system-wide.

Question for the forum

• Is there a known change/regression on the Golden Gate Public Beta where the Local Network permission prompt doesn't fire for direct-IP connections that don't go through Bonjour/NWBrowser? (The same code works fine on the Developer Beta.)

• Has anyone else seen tccutil reset LocalNetwork fail (while other services reset fine) specifically on the macOS 27 Golden Gate Public Beta?

• Any known workaround short of downgrading — e.g. restructuring the connection to use Bonjour/NWBrowser instead of a direct IP connection, or some way to explicitly trigger the permission prompt?

We're also planning to file this via Feedback Assistant with a full sysdiagnose, but wanted to check here first in case this is already a known/tracked issue or someone has a workaround.

Thanks in advance.