nesessionmanager infinite retry loop causes permanent, unfixable Local Network Access denial (System Settings UI misrepresents actual enforcement state)

Question

Created 3w

Replies 2

Boosts 1

Participants 3

Summary

On macOS 26.6.2 (25G83) (Tahoe), Chrome fails to load pages hosted on private/local IP addresses (e.g. http://192.168.0.43/, a home AV receiver's web setup page) with ERR_ADDRESS_UNREACHABLE, while Safari loads the identical URL without issue on the same Mac, same network. ping to the target IP succeeds normally. System Settings > Privacy & Security > Local Network shows "Allow" for Chrome — but this is not what's actually being enforced.

Traced the root cause to nesessionmanager stuck in an infinite retry loop when attempting to install/update NetworkExtension path-rule policies. Because the daemon never completes a successful policy install, nehelper (the actual enforcement point) continues serving a stale cached "denied" decision indefinitely, regardless of what the Settings UI shows or how many times the toggle is flipped.

Key evidence

Chrome netlog (chrome://net-export/) shows a genuine TCP connect attempt (not an early permission rejection):

text TCP_CONNECT_ATTEMPT --> address = "192.168.0.43:80" -TCP_CONNECT_ATTEMPT --> os_error = 65 -TCP_CONNECT --> net_error = -109 (ERR_ADDRESS_UNREACHABLE) os_error = 65 is BSD EHOSTUNREACH, returned by the kernel at the connect() syscall.

Unified log (log stream --predicate 'subsystem == "com.apple.networkextension"') shows the actual enforcement decision:

text nehelper: UUID cache hit for com.google.Chrome nehelper: Local network denied by preference for Google Chrome (com.google.Chrome) This reproduced identically across multiple attempts, minutes apart, and survived sudo pkill -f nehelper — confirming the decision is persisted, not just an in-memory cache.

While toggling the Local Network switch in System Settings, expecting a pathRules dump, the log instead showed:

text NESMPathControllerSession[...]: No UUIDs in the cache for PathRuleDefaultNonSystemIdentifier, populating the cache from the path rules NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 1 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 2 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 3 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 4 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 5 The retry counter kept incrementing with no observed successful completion, meaning any change made via the System Settings toggle can never actually propagate to nehelper.

Also confirmed Local Network privacy is not TCC-backed at all:

text $ sudo tccutil reset LocalNetwork tccutil: Failed to reset LocalNetwork

$ sudo tccutil reset LocalNetwork com.google.Chrome tccutil: Failed to reset LocalNetwork approval status for com.google.Chrome Both fail outright rather than erroring on bad usage, confirming this permission lives entirely in the NetworkExtension path-rule system, with no supported reset command.

What did not fix it

Toggling the Settings UI switch off/on

sudo tccutil reset SystemPolicyNetworkVolumes (wrong TCC service — doesn't apply here)

sudo tccutil reset LocalNetwork (fails, see above)

Full clean reinstall of Chrome, including all Application Support/Caches/Preferences

Safe Mode boot

sudo pkill -f nehelper

Full normal system restart

Launching Chrome with --no-sandbox (rules out Chromium's own internal sandbox as a factor — this is a system-level enforcement, not a Chromium-side block)

Working fix

Requires temporarily disabling SIP:

text

In macOS Recovery (csrutil only works from Recovery, not Safe Mode):

csrutil disable

Back in normal macOS:

sudo rm /Library/Preferences/com.apple.networkextension.plist

Back in Recovery:

csrutil enable Restart normally. nesessionmanager rebuilds the NetworkExtension policy state from scratch on next boot. System Settings > Privacy & Security > Local Network shows a clean list afterward (also clears the separate, previously-known bug where every Chrome auto-update was creating a new duplicate entry in that list rather than updating the existing one). Chrome's next navigation attempt to a local IP correctly triggers a fresh permission prompt, and functions normally once granted.

Why this matters

Apple's own TN3179 states there's no supported way to reset an app's Local Network privilege to "undetermined." This bug compounds that: once nesessionmanager gets stuck in this retry loop, there is no path back to a working state short of disabling SIP and manually deleting a system preference file. The Settings UI also actively misrepresents the true enforcement state (shows "Allow" while nehelper enforces "denied") with no indication to the user that anything is wrong. This is likely not Chrome-specific — any app relying on Local Network access (smart-home apps, casting/streaming apps, IoT config tools) would hit the identical wall once a Mac's nesessionmanager enters this state.

Also filed via Feedback Assistant.

Happy to share the full decoded netlog trace if useful — didn't attach it here to keep this post scannable, but can paste the additional detail on request.

Answer 1

DTS Engineer OP

Apple

3w

Also filed via Feedback Assistant.

That’s the correct path for this.

What was your bug number?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 2

quc OP

2d

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?