Add "local network access" permission for macOS 15 runners

Could you please guide us on how to add 'local network access' permission for macOS 15 and macOS 15-arm64 image runners?

First up, make sure you’ve read TN3179 Understanding local network privacy. As noted in that technote, this setting is:

• Per user

• Not settable via a configuration profile or MDM

• Not resettable via tccutil

That makes things challenging in your situation )-:

Normally CI systems don’t need local network access because the code they’re building has no reason to be accessing stuff on the local network. However, reading the issue you linked to I see that you’re trying to enable your customers to test Mac software that uses the local network. Is that right?

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

Hi, User is Attempting to test multicast sockets results in routing errors, which suggests that the code is running without "local network access" permissions.

User says that Ideally this would be configurable, so that code could be tested to ensure that it doesn't need this permission, but when it is necessary for a certain function it would be nice to have.

User says that Ideally this would be configurable

Right, that makes sense.

Unfortunately I don’t have any good answers for you here. If the code being tested is a GUI app, you have to run it in a user context, and that context is subject to local network privacy. And, as you’ve noted, there’s no way to enable that via, say, a configuration profile.

One potential option is to learn into virtualisation. So, let your customer set up a virtual machine and grant the Local Network privilege to their app there, then save that VM and restore it each time you want to test their code. That’ll likely work, but I suspect that it won’t fit well into your product’s current structure.

Beyond that, my advice is that you file an enhancement request for the feature you’d like to see, being very clear about the specific high-level use case you’re trying to handle.

Please post your bug number, just for the record.

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

I am the user in question, so I guess I might as well chime in directly.

let your customer set up a virtual machine and grant the Local Network privilege to their app there

In this specific case, it's not a GUI application, it's a Python library, which has some multicast logic in it. Are you suggesting that the only option now is to block every test run on a user manually VNCing into a cloud CI backend to manually click on some GUI preferences? As you might imagine, this is not feasible either for an open source library that needs to accept volunteer contributions or a hosted CI service with ephemeral test runners.

(The practical upshot of this is that we will need to treat macOS as a platform which can no longer support multicast sockets, which would be a bit of a bummer.)

Bug number: FB16213134

Hi , Any update on the issue?

Hello, Is there any feature released for Add "local network access" permission for macOS 15 runners?

Sorry I didn’t respond earlier. I missed these updates.

Are you suggesting that the only option now is to block every test run on a user manually VNCing into a cloud CI backend to manually click on some GUI preferences?

No. I’m suggesting that you:

• Run your code in a valid context. That can either be:

  • A launchd daemon — This isn’t subject to local network privacy.

  • A launchd agent, or some other context that’s running in a GUI login context — You can then have the user approve its local network access once.

  Most folks who run into problems like this do so because they’re mixing execution contexts, which is a common source of weird problems on the Mac. There’s a very old, but still surprisingly valid, technote that explain this issue in gory detail: TN2083 Daemons and Agents.

• If you choose the second option, sign your code so that the system can tell that this version of your code is the ‘same code’ as the previous version.

  You can’t sign Python code, so the system will identify it by the code that loads and runs it.

• You should absolutely feel free to file enhancement requests for situations where this is causing you excessive grief. And if you do files bugs about this, please post the bug numbers, just for the record.

Bug number: FB16213134

Thanks for that.

Any update on the issue?

Update from whom?

From an Apple perspective:

• You can check the state of your bug in Feedback Assistant.

• If there are substantial changes to our local network privacy policy, you should expect to see an update to TN3179.

However, your specific issue seems to be tied to a GitHub feature. It’s not clear if you’re working for GitHub or not. If you are, I recommend that you escalate this via GitHub’s contacts at Apple. If you’re not sure who that is, open a DTS code-level support request and I can point you in the right direction. Make sure to open it from an Apple Account who’s part of the GitHub team.

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