Thank you so much for all the help! I've filed FB25019969 requesting system-wide SMAppService agent registration and asking Apple to duplicate it to r. 92457638.

Thanks, Quinn. We tried your static-plist suggestion on macOS 27.0 (26A428) in our Developer ID signed and notarized app: A root-owned plist at /Library/LaunchAgents/<agent-label>.plist has LimitLoadToSessionType=Background and AssociatedBundleIdentifiers=<app-bundle-id>. It launches the nested App Sandbox helper. Our SMAppService system daemon calls launchctl kickstart user/<serviceUID>/<agent-label>. It bootstraps that fixed plist only if the job is not loaded in the service account's domain. After a cold boot and FileVault unlock, the helper published readiness as the hidden service account while /dev/console still belonged to root, before GUI login. Turning the app off in Background App Activity stopped the daemon. Its control socket closed, so the helper exited; the agent job stayed loaded. Turning the app back on started a new daemon and helper. These are observations on one OS release. Is this static plist plus kickstart arrangement within the intended launchd and Background Task Management model for a hidden-account Background agent, including before login? On disable or unregister, should our daemon leave the agent job loaded and let the helper exit on socket EOF, removing the plist only on explicit uninstall? We can file Feedback for system-wide SMAppService agent registration if useful.

Thanks, Quinn. It depends on the setup: In the reproducer from the post, it's a fixed file inside the app bundle: /Applications/<App>.app/Contents/Library/LaunchAgents/<label>.plist, bootstrapped by that absolute path. In our current build, the daemon writes it at each start to /var/run/<label>.plist (owned by root, mode 0600) and bootstraps that file. Its ProgramArguments point at the nested helper inside the app bundle: /Applications/<App>.app/Contents/Helpers/<Helper>.app/Contents/MacOS/<Helper>. We generate it because it passes the app's build number as an argument; that could move into the helper itself. We can use whichever location you'd consider least fragile. What we're really after is both App Sandbox and a dedicated non-root identity for the helper, before login, since it parses untrusted input. Is there a supported way to get both? If not, we'd pick one of two configurations that already work for us. Which would you consider on firmer ground? SMAppService.daemon running as root, with App Sandbox. SMAppService.daemon with UserName set to the service account, without App Sandbox.