I suspect that this is a bug in local network privacy Yet another. :) Normally I recommend that folks don’t use shell scripts when user-controlled privileges, like Local Network, are involve Not sure what else I could do instead. The actual script I'm trying to run is a nightly build script of our own code. It updates from source control, invokes xcodebuild, etc. etc. (Hilarious how because our source control server is in our building, this "protection" stymies us, but if I was connecting to some random North Korean IP, that'd be fine, no permission prompts then!) This time the BSD Sockets code was able to connect Cool. Perhaps that could be a workaround... we'll try... Thanks very much for your detailed debugging and detailed reply! You have been so helpful to so many, for so long. I've given up filing bugs with Apple, but for you I'll make an exception: FB16131937

On the plus side, this all keeps me gainfully employed (-: :) I think Apple would collapse without you Quinn! The duplicate entries in System Settings (FB16131937) are unrelated to this script of ours or homebrew. They occur with our actual app's nightly builds (which this script makes). We sign and notarize builds we release to customers, but I don't recall exactly what we do with mere nightlies. They maybe use ad-hoc signing... But back to the original issue... is there still no way to manually add an executable to the list of processes allowed to make local network connections?

Sometimes my BSD Sockets code would present the local network alert correctly and everything would be fine. Interesting, because we just saw this yesterday too (for the first time ever). The cron job runs overnight and when I Screen Shared to the Mac yesterday morning there was the permission screen waiting for me to press Allow. I pressed Allow but then was too busy with other things. Looking today, the UI in System Settings now has an entry with a weird icon and the name of the Mac. Right-clicking to Reveal in Finder fails. It's like a zombie entry that falls back to a stupid icon and stupid string. I've just rebooted, and now that zombie entry is gone. I’m not sure how this translates to your setup. You’re having problems with a tool coming from Homebrew, meaning its hard to change its exit behaviour. However, if you were able to do that, it’d be interesting to see how it affects the final behaviour of the system. The actual thing we are doing is a nightly build script which uses svn/subversion (built by MacPorts) to get our latest code every night then build it with xcodebuild. Perhaps when there are many/large file changes svn runs slowly enough to make this happen or not? In all our testing, the working copy was already up-to-date and thus it ran fast. Or maybe we could use Network Link Conditioner to force everything to run like molasses? Then again, since the local connection is rejected by the OS immediately, neither of those may help. MacPorts can be told to build from source. I suppose I could hack svn to add a sleep()...

So I found the lldb incantation to wait for a process: sudo lldb -n svn -w I then launched svn via my launchagent and indeed lldb attached to it, and indeed the launchagent waited. I waited minutes, then told lldb to continue, and it did, and then the launchagent also finished. But again svn output 'no route to host', and again no permission prompt appeared for me the whitelist svn. I also updated to macOS 15.4, which has not helped.

Hallelujah! Breaking on _exit() worked! I guess it indeed boils down to the process not existing long enough. Can you add this to TN3179? :) Many thanks Quinn!

Quinn, I've never looked at the svn source code, but being cross-platform, I image they use BSD-style socket APIs. Is there some error code that indicates failure due to 'local network' permission? If so, svn could be modified to call sleep(1) in such a case...