Unclear working of Local Network Privacy feature on macOS Sequoia

there is little information about this topic on the Apple developer website

Right. I will update the Local Network Privacy FAQ at some point, but I’m still ironing out the details myself.

I noticed that the type of application accessing the local network in macOS matters - bundled or command-line (CLI) applications.

Yes and no. The location of the executable matters because of the way that TCC identifies the responsible code [1]. The other thing that matters is the execution context [2].

The TCC subsystem does not restrict access to the local network for CLI applications at all, regardless of how they are launched

That’s not true. You just happen to have hit two cases where local network privacy does not apply:

• If you run a tool from Terminal, then Terminal is considered the responsible code and, as a system app, it’s not subject to local network privacy.

• If you run an executable as a launchd daemon, it runs as root and local network privacy does not apply to code running as root.

However, if you configure the executable to run as a launchd agent, you will see local network privacy prompts [3].

Is this behaviour correct and likely to remain the same in future releases of macOS Sequoia?

Much of the behaviour you’ve described matches my understanding of how the feature is supposed to work on the Mac. It’s possible that things might change as we learn more from the seeding process [4].

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

[1] I define this term in On File System Permissions.

[2] As defined in Technote 2083 Daemons and Agents.

[3] I was testing that last night and saw some very weird behaviour (r. 132968565).

[4] I’m certainly hoping that we fix the launchd agent story.

Hello! Thank you very much for your response! We greatly appreciate the chance to discuss Apple's technologies with their engineers!

If you run a tool from Terminal, then Terminal is considered the responsible code and, as a system app, it’s not subject to local network privacy.

I have conducted more experiments and have attached the new results to FB14581221 (bundled_as_cli_term). If you run the bundled application for the first time through the terminal, a prompt will appear for the Terminal.app. This is not the case for me, but the results of the experiment don't match your expectations:

If you run an executable as a launchd daemon, it runs as root and local network privacy does not apply to code running as root.

Here my experiments also show different results - if the bundled application is launched as a launchd daemon, the prompt will appear, even though the app runs with root privileges (see "bundled_as_daemon" in the attachments for FB14581221):

The latter scenario has an impact on the user experience of my application and I would like to prepare carefully for changes in the macOS. It would be helpful if you could provide information about the expected outcomes of the scenarios mentioned.

Thanks for filing FB14581221. They’ve definitely landed in the right place, right next to my bug (r. 132968565).

At this point I’m going wait to see how that investigation pans out before I dig into this any deeper.

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

On the launchd daemon from, see this other thread for more info about what’s going on.

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

Lab-Ally has run into the same bug and it's causing us some pain. We can manually toggle the switch in local network to on, but if the computer restarts it will "forget" that this permission was granted. The user has to toggle the switch off and on again to restore access. Also, for us this only seems to affect accounts migrated to sequoia on M4 from Intel Macs with a prior OS. NEW Mac admin accounts made on the same sequioa machine are NOT affected.