Thanks once again, Quinn! To close the loop: I ended up transforming the LaunchAgent into a regular application with a Dock tile to prevent it from being killed outright during the logout orchestration. I even found some useful operations to be exposed via the tile, so it's not just a dummy UI. My upstream fixes to Home Assistant OS to speed up shutdown (https://github.com/home-assistant/supervisor/pull/7448) were also merged, so that the next release has higher chances of fitting into the 60 second budget. Until the man page is updated, this forum post serves as documentation for the ExitTimeout cap.

Quinn, is the maximum timeout configurable? Last time you helped me out by documenting AllowedEthernetLocalNetworkAddresses and AllowedWiFiLocalNetworkAddresses in tn3179, so I'm hoping for something similar to let users increase the cap.

However, there’s also an obvious downside to this, namely that the app has to show up in the Dock, app switcher, and so on. Yeah, that's precisely what I'm trying to avoid. The project is all about running Home Assistant as a (headless) background service, managed by Homebrew. The community around self-hosting on macOS is small and I understand it's not a priority for Apple. Think about this from a user’s perspective. They choose Apple menu > {Restart, Shut Down, Log Out} and their apps quit and then the system looks like it’s hung for 60 seconds. That’s not a great user experience. What I'm seeing in the Restart case is even that the VZ process gets terminated within a second an there's nothing that the host process can do about it. The resulting user experience is that after a reboot, they see an "unclean shutdown" message in the guest VM (at best) or face a data loss (at worst).

Thanks for the confirmation, Quinn! I filed FB25376334 for the documentation. For context: https://github.com/IngmarStein/havm/issues/27 is where one of my users ran into this problem. The job is a VZ VM where the guest can take longer than 60 seconds to shut down cleanly. I'd love to make that faster, but the guest OS doesn't support suspend / resume.

The host is failing to update at around the 10% mark with the MSU_ERR_PERSONALIZATION_FAILURE error. This persists even after stopping the VM or re-assigning the pased-through USB device back to the host. The personlization step only completes when I unplug the passed-through USB device. Maybe there are still some processes from Virtualization.framework hanging around, holding onto a IOKit lock.

Updated: A DFU revive rendered the Mac unbootable, but I was able to re-install macOS from a USB medium without data loss. Phew.

I've now also hit MSU_ERR_PERSONALIZATION_FAILURE which prevents me from upgrading a Mac Studio M4 (which is not in Reduced Security mode and never was) from macOS 27 Beta 2 to Beta 3. My MacBook Pro M4 upgraded just fine. The full installer runs into the same issue.

Thanks, once again, Quinn! Does https://github.com/IngmarStein/havm look like something that meets the criteria for both? I saw the thread mentioning the DTS support request but hoped for some rules that help me assess the odds.

Quinn, this is awesome, thank you so much! And wow: "The AllowedEthernetLocalNetworkAddresses and AllowedWiFiLocalNetworkAddresses user defaults debuted in macOS 15.5"

Alright, I'll watch TN3179 for updates! I don't see a revision number like 161891509 in the public docs, so I assume it's an internal reference. Hoping for good news :)

It's been a while, but I wanted to bring up the topic again in the hopes that it would increase the changes for improvements in the next major macOS release. People got very creative in the meantime and they use solutions like https://github.com/steipete/Peekaboo or https://www.hammerspoon.org to automate away the security prompts (or just run services as root). As a result, systems become less secure - the opposite of what the permission dialogs are aiming for. It would be better to allow for some flexibility and selectively disable the local network permission for people who trust their networks, the machines, and the software they install on them. Maybe there's a smart way to solve that only for certain use cases like LaunchAgents.

For posterity: the behavior seems unchanged on macOS 26.0 Beta (25A5306g). Binding to a specific IP still requires root permissions.

Thanks! I hope there's a chance of a solution materializing during Tahoe's development. In the meantime, I'll probably revert back to launch daemons because the permission problem is worse than I thought. It's one thing when I have to log in using remote desktop to re-grant permissions after upgrading Prometheus, Grafana, Alloy, or other services, but it's another when I upgrade a runtime like Pythong or .NET. In that case, I have to figure out which services use those, restart them, and then allow access to the local network and private keys in Keychain. Running as root is already not great, but launch daemons often surface another problem: because they start so early in the boot process, network interfaces might not be up yet and some services don't properly handle that case. Technitium DNS, for example, falls back to listening on a default port on all interfaces if binding fails. I've filed an issue upstream and the next version will introduce a flag which instead terminates the process, so that launchd can restart it at a later time. There are other cases like this. Just mentioning this additional context in case it helps with prioritization :)

Thanks, Quinn! I've created an enhancement request and here's the bug number as requested: FB17818651. I apologize if the "if only" came across as a bit snarky. I understand that not having such a setting is probably the right thing for macOS in the usual context of a personal computing device for end users. However, in a server context (where I guess Mac minis and Studios are quite popular), it might be warranted. Not sure if this audience is a priority for Apple. As for Homebrew: I'm not a maintainer, but as far as I know, it only provides attestations for bottles (packages), and uses ad-hoc signing for the executables contained in the packages: https://repos.openssf.org/proposals/build-provenance-and-code-signing-for-homebrew.html#macos-executable-code-signing https://github.com/Homebrew/brew/blob/1f37a11b7946b6d770ecba66a487ba325b58e49c/Library/Homebrew/extend/os/mac/keg.rb#L40

My use case is: I want to run multiple services on a Mac Studio, each binding to a different IP address, all using port 443. Ideally, I'd like to run them as a non-root user. Afaict, the options are: a reverse proxy listing on all interfaces (I'd like to avoid this additional network hop) port forwarding using PF wait for the issue discussed in this thread to get resolved and continue to run them as root in the meantime. I hope we get to see another Finally! :)