Hi, we are also affected by this issue after upgrading our Gitlab CI runners from Sonoma to Sequoia. We can no longer access our local network systems reliably. [quote='813547022, DTS Engineer, /thread/763753?answerId=813547022#813547022'] A daemon running as root can access the local network just fine [1]. An agent running in the GUI login session can access the local network subject to user approval. [/quote] Quinn, from my understanding you propose those two options as expected to be working. I sadly cannot confirm this. Option 1 (daemon running as root) raises a security concern as this would provide root permissions to the automated gitlab-runner process and its child processes. Option 2 (agent running in the GUI login session) does not appear to be working for us. https://developer.apple.com/library/archive/technotes/tn2083/_index.html mentions the different launchd agent types. We have never deviated from the default LimitLoadToSessionType Aqua (GUI launchd agent) but observe that the CI pipeline scripts cannot reliably access local network resources anymore. The automated gitlab-runner spawns a child bash process. Then in this context, what works: curl http://<local network resource> what doesn't work: python script.py which then accesses the same local network resource; resulting in OSError: [Errno 65] No route to host python was installed the following: brew install pyenv pyenv install <version> pyenv global <version> The error behavior is identical for Apple Silicon arm64 and Intel x86_64 machines. Our current workaround is to disable the launch agent completely by launchctl unload -w /Users/<user>/Library/LaunchAgents/gitlab-runner.plist and open a Terminal session after reboot which spawns gitlab-runner run <additional_args> This however is far from ideal and not well suited for automation. Quinn, do you have any advise on resolving this? Thank You

Thank You Matt, I might just stick with the agent for now. For completeness, I've been toying with ways to avoid the agent. When I unlock the default keychain prior to codesigning, it seems to work, i.e. security unlock-keychain -p <PASSWORD> I would like to note the security implications, potentially giving access to all information inside the keychain to all kinds of tasks. Best regards Maik

Hi Matt, thank you for your advise. I would like to note that I am setting the user in the job properties. <key>UserName</key> <string>dev</string> Apparently, this is not enough to setup up the proper context. Could you elaborate please how I can achieve this? I prefer a solution that automatically starts up after reboot to minimize the maintenance effort. As an alternative, is there a way to pass the certificate / signing identity differently to the codesign executable? Or would it have to reside in a keychain? Best regards Maik