Local Network permission randomly breaks connectivity, only fixable via Recovery Mode

I am currently using macOS 27 beta 4, but this issue also existed on macOS 26.5 before I updated to macOS 27. I am not sure whether earlier system versions had the same problem, as I had never encountered a similar issue before.

I am developing through the local network, including using VSCode Remote SSH to connect to a local server, and using a Swift app to establish a WebSocket connection with the local server. Recently, I have encountered multiple cases where the local server connection suddenly failed. Checking the logs showed messages such as Permission denied or similar errors. AI assistants explained that this usually means the target app does not have Local Network permission enabled in Privacy & Security settings. However, I checked the settings page and confirmed that the target apps already have Local Network permission enabled.

Previously, when VSCode Remote SSH failed, I observed the following behavior: after updating VSCode, if the local server was not running, VSCode Remote SSH immediately reported that the target server could not be found. After starting the local server, it immediately reported that there was no route to the host (I do not remember the exact English error message, but it was a common network error). Checking the logs showed Permission denied. I even noticed two VSCode entries in the Local Network permission list that could be enabled or disabled independently.

Just now, my Swift app failed in a similar way. I verified that the server was running and listening because websocat could successfully connect to the local server. The app uses Starscream, and client.connect() was executed but the connection could not be established. Checking log stream --predicate 'process == "name"' --level debug showed:

2026-08-08 14:48:38.620396 ... nw_endpoint_handler_path_change [C1 ... waiting parent-flow (unsatisfied (Local network prohibited), interface: bridge100, ipv4)]

However, after successfully applying the workaround described below, I saw the backend server print related output, proving that the server received the app's ping frame. At the same time, the Local Network permission page did not show this app as an entry, and no permission prompt appeared asking me to authorize Local Network access. Therefore, I am no longer certain that this issue is strictly related to Local Network permission.

All of the above cases involve third-party components: VSCode Remote SSH, UTM providing a server at 192.168.64.3, and Starscream instead of the WebSocket implementation provided by Foundation. I am not an expert in networking, so I cannot completely rule out issues caused by third-party software.

However, I found that running the following commands in macOS Recovery Mode:

#!/bin/bash
cd "/Volumes/Data/Library/Preferences/"
rm -f com.apple.networkextension.plist
rm -f com.apple.networkextension.uuidcache.plist
rm -f com.apple.networkextension.control.plist
rm -f com.apple.networkextension.necp.plist

and then rebooting can resolve the situation where one specific app suddenly cannot access the local network while other apps continue to work normally.

Running tccutil reset All com.bundle.id did not solve the problem. This command was suggested by Claude Sonnet 5. I am not even sure whether Local Network permission is managed by TCC, but I am including this information because the five commands above appear to modify NetworkExtension-related files rather than the TCC database.

This issue cannot currently be reproduced reliably. I do not know when it will happen. After it occurs, I have not found a normal-system-environment solution. The only workaround I have found is booting into Recovery Mode and clearing the local network authorization-related files.

Answered by DTS Engineer in 900863022

So, there are three parts to this:

  • Resetting local network privacy
  • macOS 27 beta
  • Earlier systems

You are correct that there’s no good way to reset the local network privacy subsystem. This limitation is documented as FB14944392 in TN3179 Understanding local network privacy. IMO there should be a good way to do this, and if you agree then I encourage you to file your own enhancement request for that.

This doesn’t have to be complicated. You can simply ask for it to be marked as a dup of FB14944392.


Regarding macOS 27 beta, it has a serious local network privacy bug. See this post. Given that, I wouldn’t bother spending more time investigating local network privacy issues on 27.0b4 or earlier.


Regarding macOS 26 and earlier, I encourage you to draw a distinction between development and production. Many TCC subsystems, including local network privacy [1], will encounter weird problems on your development Mac. That’s because TCC needs to track code identity, and that’s a challenge on your development machine because you are continually building and rebuilding the code.

So, when investigating local network privacy I recommend that you focus on user-level scenarios. That is, set up a clean machine and then install and use your app as a normal user would (for a Mac app, I generally do this on a VM). If you can reproduce the problem there then there’s an issue that warrants investigation. If not, then it’s generally better to just reset local network privacy on your development Mac [2] and then move on with your day.

Share and Enjoy

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

[1] Technically, local network privacy isn’t managed by TCC, but it’s reasonable to group them together in this context because local network privacy has to deal with all the same underlying problems as TCC.

[2] Which is why FB14944392 is so annoying )-:

So, there are three parts to this:

  • Resetting local network privacy
  • macOS 27 beta
  • Earlier systems

You are correct that there’s no good way to reset the local network privacy subsystem. This limitation is documented as FB14944392 in TN3179 Understanding local network privacy. IMO there should be a good way to do this, and if you agree then I encourage you to file your own enhancement request for that.

This doesn’t have to be complicated. You can simply ask for it to be marked as a dup of FB14944392.


Regarding macOS 27 beta, it has a serious local network privacy bug. See this post. Given that, I wouldn’t bother spending more time investigating local network privacy issues on 27.0b4 or earlier.


Regarding macOS 26 and earlier, I encourage you to draw a distinction between development and production. Many TCC subsystems, including local network privacy [1], will encounter weird problems on your development Mac. That’s because TCC needs to track code identity, and that’s a challenge on your development machine because you are continually building and rebuilding the code.

So, when investigating local network privacy I recommend that you focus on user-level scenarios. That is, set up a clean machine and then install and use your app as a normal user would (for a Mac app, I generally do this on a VM). If you can reproduce the problem there then there’s an issue that warrants investigation. If not, then it’s generally better to just reset local network privacy on your development Mac [2] and then move on with your day.

Share and Enjoy

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

[1] Technically, local network privacy isn’t managed by TCC, but it’s reasonable to group them together in this context because local network privacy has to deal with all the same underlying problems as TCC.

[2] Which is why FB14944392 is so annoying )-:

Local Network permission randomly breaks connectivity, only fixable via Recovery Mode
 
 
Q