How to reset (remove) apps from "Local Network" privacy settings?

App & System Services Networking Privacy

Thomas Tempelmann OP

Created Oct ’24

Replies 20

Boosts 3

Views 9.9k

Participants 7

macOS 15 has added a new "Local Network" permission under Security & Privacy.

I had a bug in my app that led to a crash when the user denied this permission. Now I've fixed it and would like to verify that it all works fine.

The problem is: I need to remove my app from the settings so that macOS will show the prompt again (e.g. to verify that my custom message appears correctly).

Usually, sudo tccutil reset All would do the trick. But not for this permission! The apps do not get cleared with this command.

So, there's two issues:

tccutil should remove it but doesn't.
How can I remove this settings?

Update

I had a look at the "TCC.db" (see https://www.rainforestqa.com/blog/macos-tcc-db-deep-dive), and it seems to me that the Local Network permission isn't even managed by the TCC system, as it doesn't appear in it. This is odd.

Answered by DTS Engineer in 809215022

I’m in the process of updating the Local Network Privacy FAQ and, as part of that, I’ve researched this question in depth. Currently there’s no good way to reset local network privacy on the Mac (r. 134842755). Personally, I get around this by running my program in a virtual machine (VM). To retest, I restore the VM from a snapshot taken before I installed your program.

Alternatively, create a new user account and run your test there. Remember that macOS maintains separate local network privacy state for each user account.

the Local Network permission isn't even managed by the TCC system

That’s correct. TCC manages many but not all of the privileges shown to the user in System Settings > Privacy & Security. Local Network and Location are the two critical outliers that I’m aware of.

Oh, and that’s one of the reasons why tccreset won’t fix this.

After some more digging, I suspect that the information is stored in the various [Network Extension preference files]

That’s very much an implementation detail. You shouldn’t rely on the presence or format of those files.

fortunately, this was done in a VM

Oh, you already have a VM for testing this? Well, that makes it easy.

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

Boost

Thomas Tempelmann OP

Oct ’24

Done: FB15568200

tdferreira OP

Jan ’25

I have a similar problem, but with a well known App... Google Chrome. I rejected the access to local network by mistake, and the toggle in "System Settings > Privacy & Security > Local Network" doesn't have any effect when I enable it.

Steps to reproduce:

Installed Google Chrome App in macOS 15.2.
Opened Chrome and tried to access a local network address
Got a prompt asking if Chrome should have permission to access the local network, replied No
Go back to "System Settings > Privacy & Security > Local Network" menu and tried to re-enable the local network access and it didn't work
Uninstalled Chrome using AppCleaner (also deleting all the related files from "~/Library/Application Support/Google")
App didn't disappear from "System Settings > Privacy & Security > Local Network" policies list.
Rebooted and the App is still listed there
Reinstalled Chrome and it didn't ask for permissions anymore
Tried to disable and then enable the local network access, it didn't work.

Tried creating a second user account, ran Chrome, accepted the permissions, worked. Tried logging in in Safe Boot with my user, to check if the toggle would have any effect, but also didn't work.

Also tried this: https://superuser.com/questions/526183/remove-applications-from-location-services-in-security-privacy-on-mac-os-x-10

But it doesn't work because apparently in macOS Sequoia we don't have permissions to edit any of those files in "/var/db/locationd/" even with sudo. Tried enabling the root user (https://support.apple.com/en-us/102367) to see if I could get around it, didn't work.

I believe this is clearly a bug that must be addressed by Apple. Would help if we could just have a way to remove the permissions for each App in that list, or if the tccutil would also reset the Local Network policies.

brokenribcage OP

Jan ’25

This is the only way to reset it:

https://forums.macrumors.com/threads/local-network-access-nightmare.2448144/post-33698401

mcorke OP

Mar ’25

We have seen similar results to those seen by the OP and others. We have submitted a separate FB incident (FB16512666) with our information and observations. For the most part it follows what others have said, though we have more to add on the inconsistency between UI and the actual permission granted. There are two related screenshots for this, the first of which shows the UI when the Local Network permission is OFF for our application called "Mbox": Screenshot - Permission OFF.png In this image you can see 10 instances of an application called "Mbox 5.2", circled in red. To the right you can see the contents of the /Library/Preferences/com.Apple.networkextension.plist file that stores the data related to the permission granted via the UI. This plist holds entries for each of the 10 instances of the application in the UI, each showing the same BundleID (com.PRG.MboxExtreme in this case) and showing a unique file path. I have drawn a red arrow pointing to one instance that has the application name "Mbox 5.2" that matches the name shown in the UI, and the state of the "DenyMulticast" boolean for that instance is circled in red - it is set to YES, which represents the result of the toggle switch in the UI being OFF. In the same image I have drawn a yellow arrow pointing to a separate instance with a different file path (and application name), and circled that instance's DenyMulticast key:value pair, which is NO, opposite to that for the other instance.

This next screenshot shows the result of toggling the UI to grant permission to the app. As noted by others, toggling any one instance of the application called "Mbox 5.2" causes the toggle for all instances to be in the same state. In the image you can see that the same instances are highlighted in the plist file, with the DenyMulticast value for the first instance now being set to NO:

Screenshot - Permission ON.png

In the first case outlined above, with permission turned off, the instance of our application called "Mbox 5.2" is NOT able to receive UDP multicast data, but ALL other instances are able to receive the same data. In the second case, with permission turned on, ALL instances of the application can receive UDP multicast.

Based on what we've seen, there's an obvious inconsistency between what's shown in the UI and what the actual permission state is. The UI seems to follow and only affect the first instance of the application. Either each instance of the application would have its own instance of the permission, or like other permissions there should be only one instance for each unique BundleID and the value affects all applications with that ID.

In addition to the inconsistency between the UI and actual operation, we have also seen in testing that even when granted permission for Local Network to an application, that after a reboot the application is unable to send/receive UDP multicast. To resolve this issue you can quit the affected app (or apps) then toggle their Local Network permission off then on again, and then relaunch the application. This state seems to hold until the next time the computer is rebooted. It is our suspicion that this issue is related to having multiple instances of the same application on the computer and the lack of consistency between UI and the plist. But we don't have any evidence of this yet.

I'll also repeat what others here and in other related posts have stated, that the concept of Local Network permission ought to have the means to test/debug the current state and also the ability to remove or reset the permissions in total or per app, As best we can tell, these items are already reported as FB8711182 and FB14944392 respectively.

auto686 OP

May ’25

Still waiting for solution.