[quote='842749022, DTS Engineer, /thread/787469?answerId=842749022#842749022'] Given that this running app is signed with a stable signing identity, I expect that you’ll be able to click Allow and won’t be bothered by this again. Is that not the case? [/quote] It seems that whenever I reboot the machine and then have it take a CI job, the problem returns. The technote is helpful, thank you. I think where we're running into problems is that we have the CI agent running as a launch agent coming from ~/Library/LaunchAgents so while it's simply executing tools from the command line, since it's not a LaunchDaemon (due to the need for an Aqua session to run UI tests) we don't fit into the clauses for bypassing this prompt right now in Sequoia. It seems that the only feasible option for us to move forward with is to figure out how to run our CI agent process as root to ensure we don't get into a state where these dialogs suddenly return for some reason. These machines are not VMs so we can't easily pre-pack them with the prompt accepted and then restore them to that state after a run. We will have to tinker with it a bit to see if the sudo and maybe some passwordless sudo helps us solve this problem. I hope to see future engagement with the feedback request I submitted about providing access to localNetwork similar to how iOS does.

Sorry, let me better explain what I meant, I typed it incorrectly in the previous post. For some additional context, we build web browsers so it's very normal for us to be running a local web server during UI/integration testing to provide web pages to test certain features with while ensuring we're not hitting the network directly to get better determinism in our tests. Here's a truncated diagram of our system architecture for CI today: [root] launchd ↳ [user] ~/Library/LaunchAgent/github.actions.runner.plist ↳ [user] xcodebuild ... test What I've prototyped is not actually moving the agent to a daemon (this is not possible due to the requirements that GitHub's runner software has. Instead, I'm proposing that we run the xcodebuild ... test command with sudo. This would modify our architecture slightly to look like this when, and only when, we run the testing job. [root] launchd ↳ [user] ~/Library/LaunchAgent/github.actions.runner.plist ↳ [user] sudo xcodebuild ... test This means we have to add xcodebuild to passwordless sudo, which feels like a reasonable trade off to us to avoid having to manually click this pop up ~100 times in a non-deterministic fashion across our build fleet. This trade off means we have to do some post-testing chmod of files that Xcode produces since the permission set it applies doesn't allow group writes, only reads. Again, this feels like a worthwhile trade off for us since the workspace are cleaned up after every job. Interested to hear what you think about this since it's different than what I previously mentioned (sorry about that!) Code Signing and Virtual Machines Since you mentioned stable identifiers and code signing I wanted to also mention our future CI/CD architecture which will use VMs (by way of Virtualization.framework) will likely have to use ad-hoc signing. Normally our application uses a set of provisioned entitlements which to my knowledge requires a code signing identity and the machine which you'd like to run the resulting binary needs to have it's UDID enrolled in the profile which was used in the signing process. Virtualization.framework does not provide a way to include a stable UDID on copies of the same virtual machine, nor does it provide a mechanism to restore a virtual machine to it's base state. We could try to do this manually, but then there's really no benefit to switch to VMs in the first place. This code signing constraint means that we're going to opt-into ad-hoc signing for CI builds that are used for local testing on that machine (this means swapping in a more limited set of entitlements which is fine by us). Since every new CI job clones and boot a fresh VM with a new UDID we'd easily blow through the registered device limits in the developer portal in no time if we had to register each one of them to use the provisioned entitlements. This would eventually stop VMs from being able to enroll themselves and get added to provisioning profiles which means builds would stop unfortunately. It's possible I'm missing some understanding of the code signing system and the available options. If I am, I'm very keen on hearing a better way to accomplish code signing with provisioned entitlements in an ephemeral environment where you can easily go through 200+ VMs (and thus UDIDs) a day. Thank you for taking the time to respond Quinn, I feel like I'm talking to a legend!

We only support macOS virtualisation on Mac hardware. Are you planning to run your own hardware? Or are you planning to build your CI system on top of a virtualisation service from another company? And if you plan to run your own hardware, roughly how many hosts are we talking about? We run 80+ physical Mac Mini's for our CI/CD needs. We're attempting to build virtualization on top of these machines to make it easier to restore the CI environment to a known, good state after runs. Today we register each machine in the developer portal and integrate it into our provisioning profiles. However, with VM through the Virtaulization.framework in order to reset to a clean state we have to boot a new VM, which gives us a new UDID. Registering each one of these would easily blow past the registered device limits stipulated in https://developer.apple.com/help/account/devices/devices-overview. I’d like to clarify my understanding of this setup. Specifically, is the ↳ symbol meant to represent a dependency? Or a flow of control? Or a parent/child relationship? This is a crude process tree, here's a better concrete example of the process tree from one of our machines You can see the Runner.Listener running in user space as a LaunchAgent from ~/Library/LaunchAgents. This means that any command that we execute through CI will be running with user permissions (not root) and also not running in Terminal.app and also not running over an ssh session. As these are the only three carveouts for the Network Privacy Extension to not show the prompt on macOS it seemed to me that sudo was the only path forward to try to get to a point where this prompt will not show up (perhaps disabling SIP is another way). Oi vey! My experience is that very little good comes from using sudo on the Mac. It has a tendency to run the resulting program in a mixed execution context, resulting in odd behaviour. For example, you might find that BSD APIs act as if you’re running as root but Security framework APIs act as if you’re running as the original user. I explain why this happens in TN2083. Yeah I don't love this either, and it is absolutely a hack, but I'm not sure what else to do to meet the needs of our business and satisfy the macOS requirements. Additionally, from my testing (as you've already pointed out) this causes issues with some of our tests that rely on things like NSHomeDirectory since that points to the one owned by root. Granted I can work around these tests since we have control over the source and can detect if we're running in CI and modify the code accordingly. Perhaps a worthwhile trade off as we're migrating to VMs that will have SIP disabled and we can restore the code and remove the hacks... I’d like to clarify “local” here. Do you point the browser at localhost, or its IP equivalent? Or at a DNS name or local IP address that just happens to be on the same machine as your running test? Or at a DNS name or local IP address that’s on a different machine, one that’s on the same local network? We will spin up a local server in the UI test process usually and reference it by way of localhost (but not exclusively, sometimes we do reference it by 127.0.0.1). Open to suggestions and ideas for how to avoid this prompt while knowing the constraints of having to run the GitHub Action runner code as a LaunchAgent, thanks again Quinn!

Here are some interesting things I've tried that have made some progress, but don't fully work. Failed Approaches AppleScript Dialog Clicker I created an AppleScript that just runs continuously in the background when a CI job starts looking for these dialogs and tries to dismiss them. It works in local testing, but not when executing through the CI process. I assume this is because it's not being run from a terminal or over SSH and that creates some kind of execution context difference which blocks the clicker from actually working when running in CI. I've tried running this as a simple shell script osascript /path/to/clicker.scpt & and through launchd with launchctl asuser $(id -u) /path/to/clicker.scpt &. I also tried using the launchctl version without putting the script in the background, but that didn't seem to work either. Run GitHub LaunchAgent as a LaunchDaemon The obvious issue is that the current LaunchAgent setup has with respect to Network Privacy is that it's not running as a LaunchDaemon, as root, or through Terminal/ssh. So I ran it as a LaunchDaemon which had it's username set to the actual CI user. This sort of worked in that the service started, and took jobs. The first issue I ran into was that codesign had some issues with the cert chain. To solve this I unlocked the System keychain and added the Apple WWDR cert to it. This made the build succeed, but the next issue was that the xcodebuild ... test command couldn't connect to the test manager process. I assume this was due to some kind of mixed execution context even though in Activity Monitor I saw the CI process executing as the CI user, not root. I wasn't sure how to better debug this particular approach so I abandoned it. It would be great to get this approach working somehow, but without more knowledge on how the processes are trying to communicate and how to better debug it I'm counting this as a failed approach. LaunchDaemon To LaunchAgent Trampoline The next thought I had was to make a new LaunchDaemon that called a shell script in /usr/loca/bin that would kick off the LaunchAgent with something like the following: if pgrep -u "$TARGET_UID" loginwindow >/dev/null; then /bin/launchctl bootout gui/"$TARGET_UID" "$AGENT_PLIST" 2>/dev/null || true /bin/launchctl bootstrap gui/"$TARGET_UID" "$AGENT_PLIST" /bin/launchctl kickstart -kp gui/"$TARGET_UID"/com.github.runner fi This worked to start the actual agent, but wasn't seen as being run from the LaunchDaemon or as root so it didn't get the carve out that is mentioned in the tech note. Untested Approaches I'm reaching the end of the idea list for how to try to get the right execution context for this runner code, so these last ideas are very hacky, but might be very direct, but lack the resilience that using a regular LaunchAgent would have. Self-SSH Script Execution Since there's a carve out for commands that are running over an ssh session I could try sshing to myself and running the github runner as a script outside of the LaunchAgent. This is kind of annoying to setup due to keys and passwords, but might be easy enough to try. LaunchAgent AppleScript I think also making a LaunchAgent that launches an AppleScript that launches Terminal.app and runs the github runner script might also work since the command execution would be from within Terminal.app which is also designated as a valid carve out. Disable SIP I've been trying to avoid this, but at this point it seems like a valid course of action if these other two attempts end up with a much more brittle solution. Again, I'd love advice or ideas on how to deal with this issue or confirm that any of these approaches is less bad than the others (they are all a little wonky!)

I ended up trying the last two approaches that I mentioned: Running the CI/CD connector directly from Terminal.app Running the CI/CD connector directly from a local ssh session I figured these last two were the most direct in trying to exercise the listed carve outs in TN3179: Understanding local network privacy | Apple Developer Documentation which states: Command-line tools run from Terminal or over SSH, including any child processes they spawn Between each of these tests I restarted the machine since it seems that that's the only reliable way to reset the state for this mechanism on macOS 15.5. Running directly from Terminal.app Here is an annotated screenshot from running directly from Terminal.app Here is a description of each numbered point of interest in this screenshot: You can see that i'm simply directly executing the script from https://github.com/actions/runner/blob/main/src/Misc/layoutroot/run.sh to run the CI/CD connector. I'm ssh'd into the CI machine from a different machine to show the process tree. You can see when I list the process tree for my Terminal process it shows that the runner process is just running in seemingly a well organized tree as the logged in user. This is the CI/CD connector running my xcodebuild ... test command from an actual CI job. Again it's running as the logged in user and is clearly inheriting from the Terminal.app process. You can observe that the Local Network Privacy prompt has been triggered. Running from a local ssh connection Here's an annotated screenshot from running from a local ssh connection Here is a description of each numbered point of interest in this screenshot: You can see in the terminal on the CI machine that I create a local ssh session through localhost and then execute the runner script from https://github.com/actions/runner/blob/main/src/Misc/layoutroot/run.sh to run the CI/CD connector. I'm ssh'd into the CI machine from a different machine to show the process tree. You can see when I list the process tree for my sshd-session it shows the runner process is running as the logged in user and produces a seemingly well formed process tree to meet the needs of the tech note. This is the CI/CD connector running my xcodebuild ... test command from an actual CI job. Again it's running as the logged in user and is clearly inheriting from the Terminal.app process. You can observe that the Local Network Privacy prompt has been triggered. 😔 I've also re-verified that the automatically created runner application is codesigned and has a stable identifier, and think I've tried to exhaust all of the different options that are available to us. So I have a few questions to ask, but also might file a TSI to try to get engineering level support... Can you confirm that this prompt is bypassed if we disable SIP on this machine? This is our last ditch option, but I'd like it to be confirmed. Is it possible this is a bug within Xcode 16.2? I've checked the release notes for Xcode 16.3, Xcode 16.4, and Xcode 26 and don't see any mentions of this kind of issue being fixed.

I have found a hack that works without disabling SIP or modifying our workflow. I revisited the AppleScript clicker idea since it seemed the most boring and easiest to peel back if Apple makes a fix in the future. I had issues with it last time since I was trying to run it within the CI workflow, but in the background since I didn't want to block execution of the actual xcodebuild ... test command, but I needed the script running before the tests kicked off in order to accept the dialog. See the following quote [quote='844634022, brian-bcny, /thread/787469?answerId=844634022#844634022, /profile/brian-bcny'] I've tried running this as a simple shell script osascript /path/to/clicker.scpt & and through launchd with launchctl asuser $(id -u) /path/to/clicker.scpt &. I also tried using the launchctl version without putting the script in the background, but that didn't seem to work either. [/quote] I suppose the problem with that approach is that the script is running in the background which means it can't click anything actually. So instead, I've created another LaunchAgent that just runs the clicker script when the user logs in and will restart it if it fails. The agent looks like this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>company.thebrowser.local-network-privacy-clicker</string> <key>ProgramArguments</key> <array> <string>/usr/bin/osascript</string> <string>/Users/{your-ci-user}/click-local-network-popup.scpt</string> </array> <key>RunAtLoad</key> <true/> <key>StandardOutPath</key> <string>/tmp/thbrws/logs/company.thebrowser.local-network-privacy-clicker.log</string> <key>StandardErrorPath</key> <string>/tmp/thbrws/logs/company.thebrowser.local-network-privacy-clicker.log</string> </dict> </plist> While the actual AppleScript looks like this: (* Continuously click "Allow" on macOS network-privacy dialogs. Save as: allow-network-dialogs-continuous.scpt Run with: osascript allow-network-dialogs-continuous.scpt This script will keep running indefinitely, clicking any matching dialogs as they appear. Use Ctrl+C to stop it. *) -- Configuration property pollInterval : 0.3 -- how often (in seconds) to check property anchorText : "find devices on local networks" -- identifying text property logActivity : true -- whether to log when dialogs are clicked -- Statistics property dialogsClicked : 0 property startTime : missing value on run set startTime to (current date) set dialogsClicked to 0 if logActivity then log "Starting continuous network dialog monitor..." log "Press Ctrl+C to stop" end if -- Run indefinitely repeat if (my clickMatchingDialog()) then set dialogsClicked to dialogsClicked + 1 if logActivity then set runtime to ((current date) - startTime) log "Clicked dialog #" & dialogsClicked & " after " & runtime & " seconds" end if end if delay pollInterval end repeat end run on clickMatchingDialog() tell application "System Events" -- Look through every window of every process repeat with proc in (every process) try repeat with win in (windows of proc) -- Quick check: does this window have an "Allow" button? if (exists button "Allow" of win) then -- Get all visible text from the window set allText to "" try set allText to (value of static texts of win) as string on error -- Some windows have no static texts end try -- Is it the network-privacy dialog we're looking for? if allText contains anchorText then -- Click the Allow button click button "Allow" of win -- Optional: log which app triggered the dialog if logActivity then try set appName to name of proc log " Dialog was from: " & appName on error -- Couldn't get app name end try end if return true end if end if end repeat on error -- Skip any processes that cause errors end try end repeat end tell return false end clickMatchingDialog -- Optional: Handle script termination gracefully on quit if logActivity and (startTime is not missing value) then set totalRuntime to ((current date) - startTime) log "Stopped after " & totalRuntime & " seconds" log "Total dialogs clicked: " & dialogsClicked end if continue quit end quit This is obviously a very ugly hack, and I'd love to replace it once I hear back with a more official solution/workaround, or some clarification on any of the assumptions I have made so far.